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Section  1 
INTRODUCTION 

\ 

The  National  Oceanographic  Data  Center  (NODC)  has 
an  obligation  to  archive  stratification  data  including  the 
modern  measurements  made  by  electronic  STDs  and  CTDs.  In  a 
companion  report  (Molinelli  and  Kirwan,  1980)  the  informa¬ 
tion  requirements  on  an  STD/CTD  system  are  determined.  In 
this  report,  NODCs  present  system  is  evaluated  in  terms  of 
its  ability  to  handle  the  required  information  and  in  terms 
of  the  cost,  speed  and  simplicity  of  the  system's  opera¬ 
tion.  These  items  are  presented  in  Section  2.  Specific 
improvements  to  the  system  are  recommended  in  Section  3. 
Appendices  are  included  which  give  more  details  than  are 
presented  in  the  text  of  this  report. 

T  • 

The  flow  of  data  and  information  through  the 
components  of  an  ideal  system  is  depicted  in  Figure  6.1  of 
Molinelli  and  Kirwan  (1980)  and  is  repeated  here  as  Figure 
1.1.  That  figure  maps  the  relationship  between  the  items 
that  are  discussed  in  this  report. 

The  system  is  required  to  handle  stratification 
data  and  station  and  cruise  information.  The  data  are 
arranged  in  cycles  which  each  contain  a  single  set  of 
parameter  values,  typically,  a  pressure,  a  temperature, 
a  conductivity  and  a  salinity  value.  A  quality  flag  value 
might  also  be  included.  Data  cycles  collected  at  several 
depths  in  the  neighborhood  of  a  single  geographic  and 
temporal  point  by  identical  procedures  are  grouped  into  a 


STD/CTD  DATA  FLOW  AT  NODC 


i  1 

!  INPUT  DATA 

GF3  Exchange  Format 
(character  based) 

INPUT  DATA 


other  formats 


INPUT 

INFORMATION 


about  data 
not  submitted 


CHARACTER 


STORAGE 


(in  Exchange  Format) 
only  if  required 
by  law 


k  AUTO 


AUTO 


Special  programming 


TEMPORARY  STORAGE 


Binary  representation 
Random  access 


Keypunching 


INVENTORY  FILE 


Sorted  by  1° 
squares,  month, 
and  year 


UALITY  CONTROL 


i  SD  II  FILE 


l  max  of  100  points 
i  merged  with  serial 
depth  data  file 


PERMANENT  STORAGE 


Binary  integers 
Packed  words 
Sequential  storage 


STD/CTD 

STANDARD  OUTPUT 


Data,  ordered  by  cruise 
or  position,  in  GF3 
Exchange  Format 
Plots 

Data  summaries 


.SD  II 

STANDARD  OUTPUT 


Compressed  data,  ordered 
by  cruise  dr  position, 
global,  SD  II  format 
Plots 

Data  summaries 


Special  programming 


SPECIAL  OUTPUT 


Data,  other  order, 
other  format 
Plots 

Data  summaries 


STANDARD  INVENTORY  OUTPUTS 


SPECIAL  INVENTORY 

4 - 

Special  programming 

OUTPUTS 

Figure  1.1 


Schematic  diagram  of  data  fiow  through  the 
NODC.  Data  flows  along  arrows  in  direction 
indicated  assuming  forms  described  within  the 
boxes.  Some  arrows  are  labelled  AUTO,  indi¬ 
cating  that  flow  along  these  paths  can  be 
controlled  automatically  by  a  system  operator 
using  standard  programs.  Only  the  AUTO  path 
between  the  INVENTORY  FILE  and  STANDARD 
INVENTORY  OUTPUTS  and  the  AUTO  path  between 
the  SD  II  FILE  and  SD  II  STANDARD  OUTPUT 
already  exist.  Some  paths  can  only  be 
traversed  by  going  through  ’’special  program¬ 
ming"  or  "keypunching." 


station.  Information  common  to  all  data  cycles  at  a  station 
is  reported  with  the  station.  Several  stations  collected 
consecutively  over  a  more  extended  space  and  time  range  are 
assembled  in  a  cruise. 

Station  information  includes  ship,  cruise  and 
station  identifiers,  and  station  time,  space  coordinates. 
Other  information  required  by  users  of  an  STD/CTD  system, 
as  specified  by  Molinelli  and  Kirwan  (1980),  include: 
surface  observations  (wind,  wave  and  weather);  classical 
measurements  (water  samples  of  salinity,  dissolved  oxygen 
and  nutrient  contents,  and  reversing  thermometer  tempera¬ 
tures  and  depths)  if  any;  collection  techniques  (instruments 
used,  drop  rates,  sampling  intervals  and  recording  rates); 
parameters  measured  (names  units,  quality  indicators  and 
default  values);  and  processing  techniques  (lag  corrections, 
edits,  filters,  derivations,  calibrations  and  interpola¬ 
tions). 


According  to  Molinelli  and  Kirwan  (1980)  user 
needs  are  met  by  an  archive  in  which  data  are  stored  on  tape 
in  cruise  order,  as  efficiently  as  possible  (efficiency  of 
storage  is  defined  later  in  the  present  report).  Quality 
control  tests  are  to  include  the  determination  and  flagging 
of  density  instabilities,  noise  level  and  vertical  resolu¬ 
tion  tests  and,  optionally,  comparisons  with  climatic  mean 
values. 

Data  are  also  to  be  degraded  in  vertical  resolu¬ 
tion  and  incorporated  in  the  serial  depth  data  file. 
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Section  2 


THE  EVALUATION  OF  NODC's  PRESENT  SYSTEM 


The  present  system  is  taken  to  be  that  described 
by  Hadseil  (1974). 

2.1  GENERAL  MEASURES  OF  A  SYSTEM 

There  are  three  basic  measures  of  a  computer  system: 

a)  Can  it  handle  the  job? 

b)  Is  it  practical  and/or  efficient  on  the  computer? 

c)  Is  it  easy  to  use? 

2.1.1  Can  It  Handle  the  Job? 

The  system  must  be  able  to  accomodate  all  param¬ 
eters  of  interest  in  the  given  area.  A  complete  parameter 
specification  includes  not  only  value,  but  units,  precision 
indications  and  even  some  sort  of  quality  control  indica¬ 
tor.  Provision  should  be  made  for  a  'not  measured'  status 
value  (i.e.,  a  dummy  value)  in  order  to  keep  data  structure 
simple. 


An  important  part  of  any  data  set  is  some  asso¬ 
ciated  comments  -  things  that  cannot  readily  be  quantified 
but  are  best  left  as  text.  Such  things  might  include 
experimentor ’ s  name,  institution  name,  processing  methods, 
simple  algorithms,  etc. 
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It  always  seems  despite  much  forethought,  that 
something  new  is  desired  in  a  system.  Additional  param¬ 
eters,  more  comments,  differing  accuracy  etc.  are  such 
examples.  The  system  must  be  flexible  enough  so  that 
upgrades  can  be  made  with  only  a  reasonable  effort. 

A  final  entry  in  this  category  could  be  called 
'responsiveness'--  does  a  system  provide  the  user  with  the 
information  needed. 

2.1.2  Is  It  Practical  and/or  Efficient  on  the  Computer? 

The  relevant  considerations  in  this  category  are 
the  following,  inter-related,  items: 

a)  Response  time 

b)  Amount  of  core  used 

c)  Running  time 

d)  Efficient  use  of  other  computer  resources 

e)  Cost 

Some  of  the  above  factors  are  heavily  influenced  by  computer 
center  considerations  totally  external  to  the  program  under 

i 

examination.  However,  they  must  certainly  be  addressed  in 
the  context  of  a  given  program. 

2.1.3  Is  It  Easy  to  Use? 


It  is  absolutely  necessary  when  designing  a 
system  or  program  to  consider  the  community  of  prospective 


I 


& 


users.  If  a  code  is  to  be  used  by  computer  scientists,  then 
things  can  be  organized  in  one  way.  However,  in  another  set 
of  circumstances,  one  should  not  be  required  to  have  the 
knowledge  of  a  computer  scientist  to  run  things.  This  is 
especialiy  true  for  the  routine  use  of  a  system.  One  must 
make  the  user  feel  that  a  system  is  trying  to  help  rather 
than  that  the  system  is  simply  one  roadblock  after  another. 
The  above  remarks  apply  equally  to  the  areas  of  job  control 
language  requirements,  input  preparation  and  output  format¬ 
ting. 


2.2 


MEASURES  OF  THE  NODC  SYSTEM 


In  this  section,  we  will  respond  to  the  evaluation 
criteria  just  described  for  the  present  NODC  system. 


2.2.1 


Can  It  Handle  the  Job? 


The  system  presently  in  use  allows  a  flexible 
and  nearly  complete  description  of  the  parameters  being 
stored.  The  value  is  provided  along  with  units,  a  precision 
indicator  and  a  quality  control  indicator.  The  system  is 
incomplete  in  that  dummy  data  values  are  n-ot  defined.  This 
forces  either  the  calculation  and  insertion  of  an  inter¬ 
polated  value  or  the  deletion  of  a  data  level.  The  system 
is  inadequate  in  allowing  only  800  characters  of  comments. 
More  comments  are  needed  to  handle  the  information  require¬ 
ments  specified  by  Molinelli  and  Kirwan  (1980).  The  limit 
of  ten  parameters  for  a  data  cycle  is  reasonable  but  un¬ 
necessarily  inflexible. 
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Finally  the  system  in  existence  in  unresponsive  to 
a  certain  degree.  It  does  not  require  and  therefore  does 
not  encourage,  the  storing  of  information  necessary  for  the 
intelligent  use  of  STD/CTD  data.  It  relies  too  heavily  on 
data  supplier's  perceptions  of  secondary  user  needs  and 
consequently  generally  fails  to  provide  necessary  details  of 
the  collection  and  processing  procedures  that  operated  on 
the  data.  This  lack  results  in  the  improper  use  of  the 
data,  i.e.,  the  data  are  used  in  the  incorrect  context.  The 
situation  could  be  improved  by  recommending  an  exchange 
format  that  requires  the  necessary  information. 

The  system  is  unresponsive  also  because  it  does 
not  routinely  channel  a  degraded  vertical  resolution  version 
of  the  data  to  the  serial  depth  data  file.  Most  of  the 
investigators  presently  clamoring  for  secondary  STD/CTD  data 
want  a  degraded  version  in  the  serial  depth  file. 

2.2.2  Is  It  Practical  and/or  Efficient  on  the  Computer? 

The  present  system  consists  of  modular  programs 
executed  in  a  batch  mode.  This  approach  does  not  have  a 
good  response  time  compared  to  the  more  modern  interactive 
time-sharing  mode  generally  available.  The  operator  of  the 
system  may  typically  wait  for  a  batch  job  step  to  run 
overnight. 

While  wasteful  of  sensible  time  and’  therfore 
personnel  costs,  the  batch  mode  does  still  enjoy  some 
efficiency.  The  amount  of  time  required  of  the  central 
processing  unit  (CPU)  is  less  (i.e.,  a  separate  CPU  is  not 
required  to  do  the  bookkeeping  associated  with  time 
sharing),  and  what  CPU  time  is  required  is  used  at  off  peak 
hours  of  the  day-  For  both  these  reasons  the  computer  cost 
per  job  is  less. 
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It  is  impossible  to  predict  the  savings  in  compu¬ 
ter  dollars  or  the  cost  in  personnel  dollars  involved  in  the 
use  of  the  batch  mode  over  a  yet  non-existent  interactive 
system.  However,  experience  has  shown  that  typically,  when 
operator  decisions  are  necessary  In  the  logical  flow  of  j 

computer  programs,  the  time,  sharing  mode  is  more  efficient.  j 

In  this  case,  the  more  rapid  return  of  results  is  a  further  ] 

bonus  of  the  interactive  mode.  An  STD/CTD  system  does  j 

require  operator  involvement  -  a  fact  recognized  in  the  j 

present  system  by  the  use  of  program  modules.  j 

I 

Other  inefficiencies  of  the  present  system  are  its 

< 

reliance  on  line  printer  plots  and  massive  data  rewrites  in 
the  data  editing  steps.  On  line  random  access  storage  of 
data,  while  expensive  to  maintain  for  long  periods  of  time, 
does  allow  corrections  to  be  entered  in  the  middle  of  a  file 
without  rewriting  all  the  unchanged  records  in  the  entire 
file.  As  a  temporary  storage  device  in  the  data  editing 


step,  random  access  disks  are  much  preferred  to  the  tapes 
presently  used.  As  for  line  printer  plots,  they  are  some¬ 
times  advantageous  over  higher  quality  flat  bed  and  drum 
plots  because  they  can  be  produced  much  faster  and  cheaper 
(and,  typically,  with  less  job  control  language).  However, 
they  have  such  poor  resolution  that  they  are  difficult  to 
use  (and  waste  personnel  time).  With  the  availability  of 
high  speed  cathode  ray  tube  (CRT)  graphics,  high  speed  and 
relatively  high  resolution  plots  can  be  produced.  CRT 
graphics  are  especially  appropriate  with  time  sharing 
operations.  What  .  is  more,  the  graphic  terminals  required 
for  their  use  are  already  available  at  NODC. 
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This  brings  up  the  point  of  hardware  requirements 
for  an  interactive  system.  The  UNI VAC  computer,  to  which 
NODC  must  adjust,  is  located  offsite.  Consequently  terminal 
interaction  will  be  required  even  to  submit  jobs  in  the 
batch  mode.  Thus  there  must  be  some  investment  in  terminal 
hardware  in  any  case.  This  hardware  is,  in  general,  applic¬ 
able  to  time  sharing  operations. 

Another  point  to  be  made  here  is  storage  space  for 
the  archived  data.  The  022  format  presently  used,  makes 
some  attempts  to  minimize  wasted  bits,  i.e.,  bits  set 
aside  for  a  parameter  but  not  needed  to  represent  the  value 
of  that  parameter.  More  savings  in  bits  can  be  realized  by 
applying  packing  and  delta  format  techniques.  These  tech¬ 
niques  and  the  savings  associated  with  them  are  discussed  in 
Section  3. 

Efficient  data  retrieval  requires  the  rapid 
identification  and  location  of  data,  without  reading  through 
the  entire  data  holdings.  This  requirement  is  met  by 
maintaining  an  inventory  file  consisting  only  of  information 
necessary  for  a  search.  The  information  should  include 
location  and  date  of  the  STD/CTD  stations  as  well  as  coun¬ 
try,  institution,  ship,  cruise  and  station  identifiers. 
NOOC  already  maintains  an  appropriate  inventory,  the  Data 
Inventory  Products  (DIP)  system,  which  can  identify  those 
stations  (by  a  unique  reference  number)  which  satisfy  a 
particular  search.  The  DIP  system  should  be  utilized  in 
processing  requests  for  data.  What  the  DIP  system  lacks  is 
a  means  of  locating  the  tape  and  file  on  which  the  station 
of  interest  resides.  A  second,  smaller  inventory  is 
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therefore  required  which  can  take  the  unique  reference 
number  provided  by  DIP  and  give  the  tape  number,  file  number 
and  record  numbers  where  the  data  from  that  station  reside 
in  the  archive. 

2.2.3  Is  It  Easy  to  Use? 

For  a  user  with  programming  background  the  design 
concepts  of  the  present  system  are  readily  understood,  but 
for  users  without,  the  methods  appear  inscrutably  complex. 
For  all  users  the  system  is  bulky.  It  relies  heavily  upon 
the  assembling  of  job  control  language  (JCL)  codes,  and  puts 
a  great  deal  of  responsibility  on  the  operator  for  tracking 
various  intermediate  forms  of  the  data.  All  job  routing  and 
edits  are  entered  by  computer  cards,  characteristic  of  older 
systems,  but  now  recognized  as  too  tedious  and  inconvenient 
to  make  proper  use  of  personnel  time  and  effort.  As  men¬ 
tioned  previously,  the  reliance  on  line  printer  plots  also 
places  a  heavy  burden  on  the  ' person  operating  the  system. 

The  difficulties  can  be  alleviated  by  establish¬ 
ing  a  terminal  based  interactive  system  with  a  "freindly" 
preprocessor.  More  details  on  this  type  of  processor  will 
be  given  in  Section  3.  Here  it  is  enough  to  describe  it  as 
a  program  that  prompts  the  operator  for  the  necessary 
information  and  then  assembles  automatically  the  modules. and 
JCL  required  to  perform  the  indicated  function(s).  The 
program  so  assembled  may  be  run  in  batch  or  interactive 
mode,  depending  upon  the  input  required  from  the  operator. 
For  operators  without  a  programming  background  the  friendly 
preprocessor  is  essential.  For  all  operators,  the  friendly 
proprocessor  makes  the  system  easier  to  use. 
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The  present  system  is  also  difficult  to  use 
because,  by  not  specifying  an  exchange  format,  it  is  forced 
to  handle  a  great  number  of  different  formats  during  data 
submission.  This  requires  a  continued  high  level  of  program¬ 
ming  effort  which  is  not  only  costly  for  NODC  but  slows  down 
the  availability  of  the  data  considerably.  While  recommend¬ 
ing  an  exchange  format  will  not  eliminate  the  need  for 
translating  different  supplier  formats,  it  could  reduce  it 
substantially. 
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Section  3 

SPECIFIC  IMPROVEMENTS  TO  THE  SYSTEM 

This  section  looks  in  more  detail  at  the  improve¬ 
ments  suggested  during  the  evaluation  of  NODC's  present 
system  in  the  previous  section.  The  elements  discussed  here 
fit  into  the  overall  ideal  system  according  to  the  map 
provided  in  Figure  1.1. 

The  improvements  described  begin  with  the  ex¬ 
change  format  because  that  specifies  all  the  data  and 
information  that  the  system  must  handle.  The  next  subsec¬ 
tion  deals  with  the  storage  of  data  within  NODC  and  the 
advantages  of  both  permanent  and  temporary  formats.  The 
role  of  the  inventory  in  data  retrieval  is  included  in  this 
subsection,  as  is  the  creation  of  data  products.  The  next 
subsection  addresses  the  friendly  preprocessor  which  pro¬ 
vides  the  means  for  the  operator  to  manipulate  the  data 
along  the  paths  marked  "AUTO"  on  Figure  1.1. 

The  final  two  subsections  deal  with  the  algorithms 
required  for  quality  control  and  compression,  respectively. 
Here  compression  refers  to  the  degradation  of  the  vertical 
resolution. 

3.1  THE  EXCHANGE  FORMAT 

Two  reasons  have  been  given  for  NODC  to  recom¬ 
mend  an  exchange  format.  One  is  to  ensure  that  the  proper 
information  is  supplied  to  NODC.  The  other  is  to  enable 


NODC  to  accept,  store  and  disseminate  the  data  more  auto¬ 
matically  and  therefore  more  rapidly.  The  GF3  system  for 
data  exchange  has  been  recommended  (Molinelli  and  Kirwan, 
1980).  This  format  enjoys  the  further  advantage  of  being 
acceptable  for  exchange  between  data  centers. 

A  complete  manual  for  the  creation  of  STD/CTD  data 
exchange  tapes  using  the  GF3  system  is  provided  with  this 
report  as  Appendix  A.  The  reader  should  refer  to  that 
appendix  for  details.  Here  we  merely  indicate  those  charac¬ 
teristics  of  general  interest. 

The  format  assembles  data  cycles  into  stations  and 
stations  into  cruises.  One  cruise  is  written  per  file.  The 
size  of  a  record  is  fixed,  but  the  number  of  data  records 
per  station  and  stations  per  file  is  variable.  The  number 
of  files  (cruises)  per  tape  is  also  variable. 

At  the  beginning  of  the  tape,  information  is 
recorded  concerning  the  institution  providing  the  tape  and 
the  date  the  tape  is  written  as  well  as  the  computer  and 
character  set  used.  A  list  of  the  cruises  contained  on  the 
tape  is  also  provided. 

At  the  beginning  of  each  file  on  the  tape  infor¬ 
mation  is  recorded  regarding  the  cruise  in  the  file,  includ¬ 
ing:  the  oceanographic  project,  if  any,  of  which  the  cruise 
is  part;  the  country,  institution  and  ship;  cruise  name; 
date  of  the  present  version  of  the  cruise  data;  dates  of  the 
cruise;  latitude  and  longitude  limits  of  the  cruise;  type  of 
data  collected;  and  the  number  of  stations  in  the  cruise. 


At  the  beginning  of  each  station  in  the  file  there 
is  a  great  deal  of  information  recorded.  As  with  the  cruise 
heading,  the  names  of  the  oceanographic  project,  country, 
institution,  ship  and  cruise  are  stored  as  are  the  date  and 
times  of  the  station  and  the  latitude  and  longitude  of  the 
station.  Surface  and  meteorological  observations  are  also 
recorded.  They  include:  water  color  and  transparency;  wave 
direction  and  period;  sea  state  or  wave  height;  wind  direc¬ 
tion;  wind  force  or  speed;  barometric  pressure;  wet  and  dry 
bulb  temperatures;  weather;  cloud  type  and  cloud  amount. 
Classical  water  sample  measurements  are  recorded  at  the 
beginning  of  the  station  also.  They  include:  pressure  or 
depth;  temperature;  salinity;  dissolved  oxygen,  silicates, 
phosphates,  phosphorous,  nitrates,  nitrites  and  pH  for 
several  levels.  Up  to  35  levels  of  classical  measurements 
can  be  accommodated.  A  code  indicates  how  these  measure¬ 
ments  are  related  in  time  and  space  to  the  STD/CTD  cast. 

The  station  heading  also  contains  information 
about  the  STD/CTD  cast  including  drop  rates,  trace  reported 
and  ship  roll  periods.  Space  is  left  for  NODC  provided 
estimates  of  vertical  resolution  and  noise  levels  for  the 
temperature  and  salinity  measurements  (see  quality  control 
algorithms  for  a  further  description  of  these  estimates). 

Relatively  complete  documentation  on  collection 
and  processing  procedures  are  required  for  the  intelligent 
use  of  STD/CTD  data.  This  information  is  stored  in  rather 
abbreviated  form  in  plain  language  comments  within  each 
station.  Information  recorded  here  includes:  name  and 
address  of  responsible  person  and  manufacturers  of  "fish", 


digitizer  and  recorder.  For  each  parameter  reported  at  the 
station  the  following  information  is  recorded:  target 
accuracy  and  precision;  sensor  serial  number;  sampling 
rates;  lag  correction  reference  and  results;  derivation 
reference;  editing  reference  and  results;  smoothing  refer¬ 
ence  and  scale;  interpolation  reference  and  frequency; 
calibration  information;  and  reference  and  results  of  other 
comparisons.  (Though  much  of  this  information  is  fixed  for 
a  given  cruise  it  is  all  repeated  for  every  station  so  that 
each  station  can  be  used  independently  of  the  others,  as  in 
a  geographic  sort.  It  is  not  unreasonable,  when  writing  a 
tape  for  data  exchange,  to  enter  this  information  into  the 
computer  once  per  cruise  and  have  the  computer  duplicate  it 
for  every  station  on  the  cruise.)  For  a  more  detailed 
description  of  the  recorded  documentation,  see  Appendix 
A. 

It  should  be  noted  here  that  the  references 
listed  in  this  portion  of  the  data  tape  must  indicate 
documents  (either  paper  or  microfiche)  available  from  NODC. 
If  the  article  referenced  is  a  cruise  report  and  NODC  does 
not  have  a  copy  of  that  report ,  then  a  copy  must  accompany 
the  exchange  tape  when  sent  to  NODC.  NODC  should  make 
copies  of  such  reports,  including  traces  of  profiles  and 
tables  of  data  in  those  reports,  available  to  users  of.  the 
data  upon  request. 

The  exchange  format  is  flexible  enough  to  allow 
many  different  parameters  to  be  used  (see  Table  7  in  Appen¬ 
dix  A)  in  any  combination  and  order.  Consequently,  before 
the  station  data  are  reported  information  must  be  recorded 
that  indicates  the  parameters,  units  and  order  chosen. 
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After  all  the  above  station  information  has  been 
provided,  the  data  cycles  are  recorded.  Though  many  param¬ 
eters  are  allowed,  three  are  crucial.  These  are  pressure, 
temperature  and  salinity.  Due  to  the  multiple  ways  salinity 
can  be  calculated  from  pressure,  temperature  and  conductiv¬ 
ity,  there  is  some  worth  in  reporting  the  measured  param¬ 
eter,  conductivity,  in  addition  to  the  derived  salinity. 
However,  this  information  is  redundant  with  the  reference 
for  the  salinity  derivation  given  at  the  beginning  of  the 
station. 

Data  submitted  in  this  format  is  to  be  read  at 
NODC  immediately.  However,  some  decisions  are  required 
before  the  data  can  be  stored.  The  parameters  in  the  data 
cycle  must  be  checked  by  the  operator  and  converted  to  the 
proper  units  (e.g.,  depths  converted  to  pressures  using  the 
inverse  of  the  algorithm  reported  for  the  derivation, 
temperatures  in  °F  converted  to  °C,  etc.).  The  comments 
must  be  read  by  the  operator  to  determine  if  any  other 
special  action  should  be  taken  and  to  ensure  that  the 
required  information  has  been  provided.  References  for 
algorithms  should  be  requested  by  NODC  from  suppliers  who 
have  omitted  them.  Meanwhile  cruise  and  station  header 
information  are  passed  to  the  inventory  (DIP  system)  auto¬ 
matically.  Data  set  status  must  be  passed  to  that  system  by 
the  operator.  More  discussion  of  the  DIP  system  is  pre¬ 
sented  in  Section  3.2. 

In  order  to  encourage  the  use  of  the  GF3  system 
NODC  should  support  it  in.  the  following  two  ways.  First, 
NODC  should  provide  FORTRAN  routines  that  will  accept 


surface  and  classical  measurements  and  arrays  of  pressure, 
temperature  and  salinity  and  generate  a  GF3  tape.  This  is 
in  order  to  simplify  the  conversion  to  GF3  for  the  minimal, 
most  basic  use  of  STD/CTD  instruments.  Also,  NODC  should 
supply  codes  that  read  GF3  tapes  and  unloads  their  contents 
into  COMMON  blocks.  Second,  NODC  should  make  a  programmer 
available,  if  at  all  possible,  to  an  institution  or  other 
data  supplier  and  help  their  programmers  establish  a  system 
to  convert  their  data.  This  programmer  to  programmer 
communication  will  help  avoid  many  of  the  errors  that  occur 
when  instructions  are  passed  through  too  many  inter¬ 
mediaries.  A  few  days  of  "troubleshooting"  at  the  major 
suppliers  will  save  NODC  much  work  down  the  line. 

3.2  DATA  STORAGE  AND  RETRIEVAL 

IFhile  the  data  are  being  viewed  by  the  operator 
to  determine  what  conversions  'need  be  made  they  are  residing 
in  the  core  of  the  computer.  Only  one  station  need  be  in 
core  at  a  time.  The  other  stations  in  the  cruise(s)  of 
interest  need  to  be  somewhere  easily  accessed  one  station  at 
a  time.  This  is  necessary  to  keep  the  number  of  input/ 
output  (I/O)  operations  to  a  minimum  which  is  crucial  to 
keep  computer  operating  costs  to  a  minimum  (see  Appendix  B, 
Section  2).  The  ability  to  access  stations  one  at  a  time 
means  some  random  access  filing  system  need  be  used.  The 
one  available  on  the  NODC  UNIVAC  is  a  bank  of  disk  packs 
with  the  storage  capacity  for  about  4000  typical  stations  at 
once  (see  Appendix  B).  At  100  stations  per  cruise,  this  is 
enough  space  for  40  large  cruises  at  once.  For  viewing 
cruises  newly  received  this  capacity  is  many  times  over  what 
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is  needed.  For  the  limited  geographic  sorts  to  be  supported 
by  this  system  during  dissemination  the  capacity  for  40 
cruises  of  randomly  accessible  stations  is  very  likely  to  be 
sufficient.  For  the  rare  cases  when  it  is  not,  a  several 
step  sort  can  accomplish  the  job. 


To  retrieve  data  from  the  disc  a  catalogue  must 
be  maintained  that  gives  the  disc  record  number  (of  the 
first  record  if  the  station  requires  more  than  one)  for 
every  station  on  the  disc.  The  operator  indicates  the 
station  of  interest  and  that  station  is  automatically  loaded 
to  core  for  viewing.  The  decisions  are  then  made  and 
conversions  performed  and  the  data  from  that  station  can  be 
rewritten  to  the  disc,  overriding  the  previous  version. 
When  all  such  changes  have  been  made  to  the  data  set  it 
should  be  transferred  to  permanent  storage. 

Unlike  the  temporary  disc  storage  described, 
the  permanent  storage  should  be  as  compact  as  possible  and 
reside  on  tape.  Techniques  for  compaction  are  described  in 
Appendix  B.  The  motivation  for  compaction  is  once  again 
that  operating  costs  are  dominated  by  a  large  number  of 
input/output  operations.  Variable  length  records  with 
maximum  sizes  as  large  as  possible  are  recommended  to 
reduce  I/O  operations  and  yet  handle  very  different  types  of 
records  (i.e.,  short  text,  long  data,  etc.).  Many  different 
cruises  should  fit  on  a  single  tape  (see  Appendix  B).  The 
sequence  of  information  and  formats  are  illustrated  in 
Figure  B.l. 


There  is  a  fundamental  requirement  for  the  capac¬ 
ity  to  locate  a  particular  set  of  stations  in  the  archive 
given  either  limits  of  time  and  position  or  cruise  name  and 
station  limits.  An  inventory  file  must  be  maintained  to 
perform  that  function. 

NODC  identifies  any  station  it  posses es  by  using 
an  "accession"  number,  "reference"  number  and  "consecutive" 
number.  The  accession  number  identifies  the  data  tape 
shipment  received  at  NODC.  The  reference  number  identifies 
separately  individual  cruises  within  a  shipment.  The 
consecutive  number  identifies  the  stations  or  records 
contained  in  the  cruise. 

NODC  maintains  a  system  called  Detailed  Inventory 
Products  (DIP)  which  can  identify  stations  that  fall  within 
any  specified  one  degree,  or  standard  ten  degree  square. 
The  system  can  further  discriminate  by  date,  if  desired, 
automatically.  A  particular  cruise  of  interest  can  be 
identified  simply  by  checking  a  list  of  reference  numbers 
that  contains  ship  name,  country  and  dates  as  well.  The 
stations  so  identified  can  be  plotted  on  a  map  or  listed 
with  any  of  the  following  elements:  file  type,  accession 
number,  country,  project  name,  reference  number,  cruise 
name,  platform  code  (i.e.,  ship  code),  station  date,  station 
latitude,  station  longitude,  station  number,  ten  degree 
square,  one  degree  square  and  parameter  codes. 

Having  identified  the  stations  of  interest, 
the  task  still  remains  of  locating  the  tape,  file  and 
records  in  which  the  station  data  reside  in  the  permanent 
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archive.  This  function  is  not  performed  by  DIP.  A  second 
sinal  ler  and  simpler  inventory  is  required.  It  should  be 
ordered  by  accession,  reference  and  station  numbers  and 
should  contain  the  tape  number,  file  number,  first  record 
and  last  record  of  the  identified  station.  Searches  would 
still  be  performed  using  DIP,  but  the  DIP  results  would  then 
be  translated  to  data  location  by  means  of  the  second 
inventory.  This  second  inventory  can  be  called  the  Data 
Location  Inventory.  The  cost  of  creating  and  maintaining 
the  Data  Location  Inventory  would  be  minimal  and  its  exist¬ 
ence  essential  to  the  rapid  retrieval  of  STD/CTD  data. 

Another  purpose  of  an  inventory  is  to  direct 
users  to  the  location  of  data  not  held  by  NODC.  Specialized 
uses  of  STD  and  CTD  instruments  fall  into  this  category  of 
data.  The  names  of  institutions  and  individuals  maintaining 
control  of  the  data  should  be  made  available.  This  type  of 
information  is  now  available  '  from  the  Environmental  Data 
Base  Directory  maintained  by  EDIS.  Information  received  by 
NODC  regarding  STD/CTD  data  not  supplied  to  NODC,  should  be 
turned  over  for  inclusion  in  the  Environmental  Data  Base 
Directory. 

Once  the  data  have  been  located  and  retrieved, 
standard  products  can  be  created  from  the  temporary  file 
including  plots  and  copies  of  data  in  either  cruise  or 
(limited)  geographic  order. 
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OPERATOR  LOAD  AND  THE  FRIENDLY  SYSTEM 


3.3.1  Introduction 

As  we  have  seen  from  Section  2,  the  NODC  system 
is  generally  reasonable  in  that  there  is  no  gross  computer 
waste  (although  there  is  definite  room  for  improvement,  as 
discussed).  It  falls  farthest  short  as  far  as  user  is 
concerned.  SAI  has  had  two  projects  in  the  past  years  that 
demonstrate  how  a  "friendly"  system  should  be  designed. 
There  are  several  relevant  considerations. 

Depending  on  the  nature  of  the  tasks  to  be  per¬ 
formed,  the  job  control  language  can  become  very  long  and 
complicated.  The  working  scientist  should  be  spared  these 
details  which  certainly  do  not  interest  him. 

Good  interactive  programs  associated  with  graphics 
terminals  with  their  quick  response  time,  flexible  nature 
and  helpful  prompts  are  very  much  preferable  to  operating 
with  punched  cards  and  a  (probably  more)  rigid  batch  system. 
In  particular,  interactive  programs  can  free  the  user  from 
all  sorts  of  tedious  formatting  details. 

Some  segments  of  a  complex  task  are  suited  .for 
batch  work  and  specifically  not  interactive  work  because 
of  computer  considerations:  run  time,  core  requirements, 
physical  tape  usage,  etc. 

Hard  copy  data  plots  can  be  a  big  help  in  the 
interactive  analysis.  It  may  not  be  feasible  to  produce 
these  during  an  interactive  session 
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Depending  on  the  job,  some  quiet  thinking  away 
from  the  computer  may  be  quite  important.  A  scientist 
should  have  a  good  plan  of  action  before  addressing  a 
computer  terminal. 

Almost  all  present  computer  systems  have  the 
capability  for  a  running  job  to  generate  another  job  stream 
(including  JCL)  on  a  mass  storage  device  and  trivially  ship 
this  generated  job  off  for  batch  execution. 

All  of  the  above  considerations  are  directly 
relevant  to  the  NODC  problem.  We  make  one  additional 
assumption  before  proposing  a  solution:  the  existence  of  a 
robust  inventory  file  computerized  and  of  modest  size  that 
will  know  about  all  relevant  cruises,  experiments,  types  of 
measurements  etc.,  and  also  where  the  data  are  stored  -  tape 
number,  file  number,  etc.  This  inventory  file  is  discussed 
in  Section  3.2. 


The  basic  tasks  performed  by  this  system  are 
to  interrogate  the  inventory  file,  locate  relevant  data 
(by  area,  cruise,  etc.),  recover  the  data  from  archives  to  a 
usable  working  form  and  perform  automated  quality  control  or 
analysis  as  desired.  In  addition  the  system  must  provide 
data  plots  and  edits  for  the  scientist/operator  plus  re¬ 
levant  summary  information  results  of  automated  tests, 
possible  and/or  probable  errors  or  problem  areas.  These  can 
be  studied  "off-line".  Also,  it  must  provide  "friendly" 
means  for  the  scientist/operator  to  use  his  judgement  in 
modifying  the  files  by  the  addition  of  flags  on  the  data, 
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quality  control  comments,  narrative  comments,  data  conver¬ 
sions  etc.  Finally,  the  system  must  provide  a  wrap-up 
capability  to  update  archive  files  and  inventory.  Such  a 
system  is  illustrated  in  Figure  3.1.  The  various  steps  in 
this  system  are  discussed  in  Section  3.3.2  to  3.3.5. 

3.3.2  Step  1 

This  is  an  interactive  preprocessor.  The  user 
will  be  asked  what  sorts  of  data  sets  he  is  interested  in: 
by  time,  data  type,  spatial  area,  cruise  name  or  by  any  of 
the  other  keys  present  in  the  inventory  file.  The  user  will 
also  be  asked  what  is  to  be  done  with  data  sets  meeting  the 
stated  criteria.  Several  options  come  readily  to  mind. 

•  Retrieve  for  further  processing. 

•  Provide  lists  and  or  plots. 

•  Provide  a  copy  of  the  data  for  external 
distribution. 

•  Perform  statistical  tests  on  the  data. 

•  Convert  data  and  modify  flags 

The  preprocessor  will  then  construct  a  file  (on  mass  stor¬ 
age)  which  will  be  forwarded  for  batch  execution.  all 
relevant  job  control,  including  requests  for  physical 
tapes,  permanent  ('cataloged')  file  activity,  attaching 
and  execution  of  pre-existing  processors  and  other  resource 
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Figure  3.1  Schematic  diagram  of  the  flow  of  program  control  under 
a  "friendly"  interactive  preprocessor. 


requests  will  be  automatically  generated.  Any  necessary 
"data  cards"  will  also  be  created.  This  file  need  never 
exist  (unless  desired)  as  a  physical  card  deck  since  it  is 
simply  forwarded  for  batch  execution.  The  scientist/ 
operator  is  almost  totally  freed  from  any  purely  computer- 
related  details  such  as  JCL  generation  physical  tape 
counting,  etc.  which  are  totally  peripheral  to  his  inter¬ 
ests  . 

3  3.3  Step  2 

This  is  the  job  generated  by-  the  preprocessor. 
It  encompasses  all  of  the  likely  actions  that  should  be 
relegated  to  a  batch  mob.  Physical  tape(s)  will  be  re¬ 
quested  and  desired  data  sets  retrieved.  The  data  may  be 
reformatted  and  saved  into  a  random  file  (unpacked,  from  the 
permanent  format  for  ease  and  efficieny  of  further  use). 
Statistical  tests  which  may  involve  some  number  crunching 
belong  here,  as  do  the  generation  of  large  edits,  graphical 
displays  and  summary  information.  The  entire  process  might 
possibly  terminate  with  this  step  if  the  sole  desired  action 
is  the  generation  of  a  data  set  copy  (in  any  of  several 
forms)  for  external  distribution.  At  this  point,  we  have 
the  desired  data  sets  made  available  for  further  work. 
The  scientist/  operator  is  also  armed  with  quite  a  .bit 
of  information  (plots  and  results  of  statistical  tests) 
about  the  data.  He  may  well  want  to  study  things  before 
proceeding. 

3.3.4  Step  3 

This  step  returns  to  the  interactive  mode. 
The  scientist  may  want  to  modify  the  data  sets  by  the 
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addition  or  deletion  of  data  flags  addition  of  quality 
control  comments,  addition  of  further  explanatory  text, 
etc.  Note  that  as  a  result  of  the  batch  job,  the  data  file 
is  currently  stored  in  some  random-access  format  which  is 
efficient  for  the  type  of  processing  to  be  done.  Output 
from  this  session  might  include  edits  and  plots,  on  paper  or 
on  the  graphics  screen,  and  (probably)  a  modified  copy  of 
the  internal  working  version  of  the  data  set.  This  inter¬ 
active  job  will  also  generate  a  file  for  batch  execution,  as 
did  step  1,  when  needed. 

3.3.5  Step  4 

This  batch  job  (generated  by  Step  3)  will  take 
care  of  clean-up  details  most  appropriately  handled  in  a 
batch  job.  These  would  include  down-loading  (packing  and 
compression)  the  data  file  for  efficient  permanent  storage, 
updating  archive  tapes  and  updating  the  inventory  file. 

3.3.6  Summary 

This  system  of  codes  is  totally  responsive  to  the 
user.  He  is  freed  from  computer  demands  or  knowledge  that 
are  irrelevant  to  him.  The  job  is  broken  down  into  logical 
steps  which  are  handled  in  the  most  efficient  place  and 
manner  for  the  specific  steps  -  either  interactive  or 
batch 


The  user  can  be  provided  with  supplemental  infor¬ 
mation  before  starting  the  second  interactive  step  (Step  3). 
Thus,  a  good  "battle  plan"  for  that  step  can  be  devised. 
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It  should  not  take  a  large  effort  to  produce 
an  original  minimal  system  that  is  responsive  to  the  user. 
As  long  as  some  reasonable  care  is  exercised  in  the  original 
coding,  new  capabilities  may  readily  be  added  at  a  later 
date. 

3.4  QUALITY  CONTROL  ALGORITHMS 

By  means  of  the  friendly  system  described  above 
it  can  be  assumed  that  the  data  from  one  or  more  stations 
resides  in  core  while  other  stations  from  the  same  cruise, 
at  least,  are  randomly  accessible  on  disc.  The  station(s) 
in  the  computer  memory  must  be  quality  controlled.  The  pro¬ 
cedures  for  Quality  Control  recommended  by  Molinelli  and 
Kirwan  (1980)  include  a  test  against  local  standards,  a  test 
for  density  instabilities,  and  tests  for  noise  level  and 
vertical  resolution  of  the  temperature  and  salinity  pro¬ 
files.  Optionally,  a  calibration  check  against  precise 
models  of  deep  water  potential  temperature,  and  salinity 
curves  is  suggested.  This  section  gives  a  more  detailed 
description  of  the  algorithms  to  be  used  to  perform  the 
necessary  quality  inspections. 

3.4.1  Test  Against  Environmental  Models 

Available  at  NODC  are  models  of  salinity  as  a 
function  of  density  (o^)  in  areas  of  5°  latitude  by  5° 
longitude  (D.  Hamilton,  NODC.  personal  communication). 
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These  models  are  rather  gross  because  of  the 
great  variability  in  the  natural  waters  they  attempt  to 
describe.  Consequentially  data  are  grouped  in  large  bins  of 
salinity  (.l°/00)  and  dt  (.05  to  .10).  Such  groupings 
can  certainly  not  test  the  calibration  of  STDs  or  CTDs  but 
they  are  capable  of  discerning  some  spurious  values  that  the 
originators  might  have  missed.  They  are  ideally  suited  for 
the  system  described  herein  for  they  have  been  designed  to 
be  used  with  an  interactive  graphics  terminal  In  this  use, 
plots  are  drawn  of  observed  pairs  of  S,  o  t  values  against 
a  model  with  an  envelope  of  acceptable  salinity  values  as  a 
function  of  for  the  appropriate  location.  Spurious 
values  of  salinity  are  most  obvious  to  the  operator  in  this 
mode  (see  Figure  3.2).  He  may  then  indicate  those  points 
whose  values  are  believed  spurious  and  have  the  quality 
control  program  flag  them  as  questionable  (see  Table  A. 8  in 
Appendix  A  for  a  system  of  flag  codes).  Note  that  the  left 
most  observation  in  Figure  3.2  should  not  be  considered 
spurious  as  it  is  in  line  with  the  following  points. 


Errors  in  temperature  are  more  subtle  as  they 
may  alter  the  o t  value  without  bringing  the  point  out  of 
the  salinity  envelope.  However,  if  temperature  is  far 
enough  in  error  density  inversions  will  result.  These 
temperature  errors  should  be  apparent  from  the  stability 
test  described  next. 


3.4.2  Test  for  Density  Instabilities 

This  test  should  be  applied  on  a  point  by  point 
basis.  Each  point  deeper  than  a  previous  point  whose  local 
density  is  less  than  the  previous  point  (density  calculated 
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Figure  3. 


2  Interactive  graphics  display  of  salinity- 
density  model  (lines)  and  observed  data 
(crosses).  Figure  provided  by  D.  Hamilton 
of  NODC. 


at  the  same  local  pressure  for  both  points)  causes  a  failure 
of  the  test.  Both  the  deeper  and  the  shallower  point  are 
in  question  but  further  inspection  is  required  to  determine 
which  is  in  error.  NODC  is  only  to  flag  such  instabilities 
and  is  not  to  make  corrections.  The  shallower  point  should 
be  flagged  as  leading  to  a  density  instability  by  virtue  of 
having  too  great  a  density  (flag  code  100,  see  Table  A. 8) 
and  the  deeper  by  virtue  of  having  too  small  a  density  (flag 
code  200,  see  Table  A. 8).  If  the  next  deeper  point  is  also 
less  dense  then  what  is  now  the  middle  point  it  also  is 
flagged  as  a  minimum.  In  this  comparison  the  middle  point 
is  the  maximum,  so  it  is  flagged  again  by  the  addition  of 
flag  100.  (It  now  has  a  flag  value  of  300  indicating  it  is 
unstable  both  with  respect  to  the  point  above  it  and  the 
point  below  it.) 

For  performing  this  test  the  temperature  (Tl, 
T2 )  and  salinity  (SI,  S2)  values  of  both  points  being 
compared  are  required  as  are  the  pressures  (PI,  P2 ) . 
The  numeral  1  refers  to  the  shallower  point. 

The  local  density  for  the  comparison  is  then 
determined  by  the  following  steps: 

•  Determine  the  average  pressure,  PA  =  1/2  (PI  + 
P2). 


•  Compute  the  adiabatic  change  in  temperature  to 
bring  point  1  to  the  pressure  PA.  The  adiabatic 
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gradient  for  water  as  a  function  of  (in  situ) 
temperature,  salinity  and  pressure  is  cal¬ 
culated  using  the  formula  of  Bryden  (1973). 
This  gradient,  G1 ,  is  then  multiplied  by  the 
pressure  difference  (PA  -  PI)  to  give  the 
temperature  change  ATI. 

•  Similarly  compute  A T2  *  G1  x  (PA  -  P2). 

•  Calculate  the  in  situ  density  of  water  1  at 
pressure  PA.  This  is  a  function  of  T1  +  A  T1 , 
SI  and  PA.  The  equation  presently  accepted  as 
standard  is  the  Ekman  (1908)  formula  although  a 
new  set  of  equations  is  presently  being  devel¬ 
oped.  The  Ekman  formula  gives  a  value  of  the 
specific  volume  which  is  the  reciprocal 
of  the  density. 

•  Similarly  calculate  the  in  situ  density  of  a 
water  parcel  with  temperature  ■  T2  +  A  T2 , 
salinity  =  S2  and  pressure  =  PA. 

•  Compare  these  two  values  to  determine  if. 
point  1  is  denser  than  point  2.  To  be  con¬ 
sidered  significant  the  difference  must,  be 
greater  than  the  effect  of  measurement  error  on 
the  calculation.  An  appropriate  tolerence 
would  be  .01  os,t>p  units. 
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The  station's  T  and  S  profiles  and  a  profile  of 
la3jt  p  should  then  be  plotted  on  an  interactive  graphics 
terminal  with  points  leading  to  instabilities  marked  This 
will  enable  the  operator  to  determine  whether  the  program  is 
proceeding  in  a  reasonable  fashion  and  whether  there  might 
be  some  simple  correction  for  a  great  number  of  instabili¬ 
ties  (e.g.,  a  block  of  data  being  reported  in  order  of 
decreasing  pressure!).  Experience  has  shown  that  it  is 
unwise  to  process  data  in  any  way  without  being  able  to  view 
them  along  the  way. 

3.4.3  Test  for  Noise  Level  and  Vertical  Resolution 

This  test  determines  the  vertical  wavenumber 
energy  spectra  of  the  temperature  and  salinity  profiles  in 
order  to  select  those  points  at  which  the  spectra  flatten. 
The  vertical  wavenumber  at  the  selected  point  indicates  the 
effective  vertical  resolution  The  energy  level  of  the 
selected  point  represents  the  energy  level  of  the  noise  in 
the  flat  portion  of  the  spectra.  This  level  integrated  over 
the  wavenumber  band  gives  an  estimate  of  the  total  variance 
of  the  noise  of  the  temperature  or  salinity  measurements. 

This  test  requires  operator  involvement.  The 
system  should  present  the  spectrum  on  an  interactive  gra¬ 
phics  terminal  (as  a  log  vs.  log  plot)  and  let  the  operator 
grapically  select  the  point  at  which  leveling  commences.  If 
no  flattening  is  observed  then  no  estimate  of  the  noise 
level  can  be  made  and  the  effective  vertical  resolution  is 
the  provided  vertical  resolution. 

This  test  is  not  performed  on  a  station  by  station 
basis,  but  on  a  cruise  by  cruise  basis. 
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•  The  cruise  should  be  searched  for  several  (5  to 
10)  of  the  deepest,  most  continuous  stations 
that  share  a  common  set  of  sensors  (i.e.,  the 
reported  sensor  serial  numbers  for  the  temper¬ 
ature,  salinity  and  pressure  measurements 
should  not  vary  among  the  stations  selected). 

•  The  greatest  common  depth  interval  among 
the  stations  should  be  determined.  Missing 
values  should  have  interpolated  values  inserted 
in  their  place  so  that  a  uniform  pressure 
series  results. 

% 

•  First  difference  (prewhiten)  the  points  along 
the  profile  to  prevent  the  overwhelming  of 
spectral  estimates  by  the  high  energy  low 

wavenumber  (long  wavelength)  components. 

/ 

If  is  the  it'h  element  of  the  original 

w 

profile  and  Xj.’  of  the  prewhitened  profile, 
then  define  Xj/  =  +  \  -  Xi. 

•  To  avoid  contamination  of  high  wavenumber 
components  apply  a  cosine  taper  to  the  first 
and  last  10%  of  the  record.  The  cosine  taper 
starts  the  profile  at  zero  and  brings  it.  to 
full  value  over  half  a  sinusoid  in  the  first 
10%  of  the  record.  In  the  last  10%  of  the 
record  the  cosine  taper  brings  the  profile  from 
its  full  value  to  zero,  again  over  half  a 
sinusoid.  This  reduces  the  total  energy  in  the 
spectrum  to  be  produced  by  10%. 
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•  Generate  a  spectrum  of  the  profile  using  fast 
Fourier  Transform  (FFT)  techniques. 

•  Recolor  the  spectrum  using  a  factor  (F)  that  is 
a  function  of  the  vertical  wavenumber  bin. 


where  n  =  the  number  of  values  in  the  input 
series  (a  power  of  2)  and  k  is  an  index  that 
goes  from  1  to  n/2  for  the  n/2  wavenumber 
bins 

•  Correct  the  total  energy  in  the  spectrum  by 
dividing  the  level  in  each  bin  by  0.9.  This 
step  compensates  for  the  effects  of  the  cosine 
taper. 

•  Do  the  above  procedure  for  each  station  select¬ 
ed.  Average  the  spectral  levels  in  each  bin 
for  all  the  stations.  Display  the  ensemble 
average  spectrum  on  a  log  log  plot. 

To  aid  the  operator,  the  plot  should  be  displayed 
on  an  interactive  graphics  terminal.  Allow  the  operator 
several  tries  at  fitting  a  straight  line  through  the  portion 
of  the  spectrum  at  vertical  wavenumbers  lower  than  the  flat, 
noise  dominated,  portion.  The  operator  indicates  two 
wavenumbers  between  which  a  least  squares  line  is  fit.  The 
line  is  extrapolated  to  high  wavenumbers  as  a  guide.  The 
operator  then  selects  a  point  on  the  line  at  which  the 
energy  level  is  the  same  as  the  flat  part  of  the  spectrum. 
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Figure  3.3  An  ensemble  vertical  wavenumber  (k)  spectrum 
of  salinity  variations  (Fs)  at  five  STD  stations 
in  the  northeast  Atlantic  on  a  log-log  plot. 
Fs(k)  has  units  of  (°/oo)2/(cycles/dbar) 
and  k  of  cycles/dbar.  A  plot  with  a  linear 
wavenumber  axis  demonstrated  flattening  at 
the  high  wavenumbers  which  is  not  so  apparent 
on  this  log-log  plot.  The  noise  level  is 
approximately  10-5( °/oo)2/ (c/dbar )  and  occurs 
at  a  wavelength  of  10*42  *  2.63  decibars.  The 
original  data  were  reported  at  one  decibar  and 
.01  °/oo  increments.  The  wavenumber  band  is  0  to 
.5  cycles/dbar  and  the  expected  noise  due  to  the 
quantizing  interval  is  .003  °/oo.  The  observed 
rms  noise  is  V.  5xl0-5  ~  .003°/oo,  in  agreement 

with  the  quantizing  noise.  Because  of  the 
exceedingly  low'  energy  at  the  high  wave- 
numbers  it  is  suspected  that  these  data  were 
low  pass  filtered  before  rounding  to  the  nearest 
.01°/oo.  If  this  is  so  there  is  probably  more 
noise  in  the  lower  wavenumbers  than  can  be 
estimated  from  the  high  wavenumbers  and  the 
•003°/oo  rms  noise  is  an  underestimate. 
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One  half  the  vertical  wavelength  associated  with 
the  vertical  wavenumber  of  this  point  is  stored  on  all 
stations  of  the  cruise.  It  is  the  effective  vertical 
resolution  of  that  parameter  (T  or  S)  during  that  cruise. 
(Note,  the  station  header  indicates  whether  a  particular 
station  contributed  to  the  ensemble  average.) 

The  energy  level  of  the  selected  point  is  multi¬ 
plied  by  the  high  wavenumber  cut  off  of  the  spectrum.  The 
square  root  of  this  number  is  taken  to  be  the  rms  noise  of 
the  parameter  (T  or  S).  This  value  is  also  reported  for  all 
stations  on  the  cruise. 

An  example  of  this  procedure  is  illustrated  in 
Figure  3.3. 

3.5  COMPRESSION 

For  the  climatological  uses  of  STD/CTD  data  a 
profile  reduced  to  under  100  points  and  inserted  in  the 
Serial  Depth  Data  file  is  normally  sufficient  (Molinelli 
and  Kirwan,  1980).  Standard  levels  no  farther  apart  than 
200  meters  are  desirable  as  are  inflection  points  that 
preserve  the  major  features  of  the  plot.  Therefore,  the 
following  compression  scheme  is  recommended. 

First,  convert  pressures  to  depths  using  calcula¬ 
tions  of  in  situ  specific  volumes,  gravity  and  the  equation 


Z 


* 


dP 


where 


pressure  of  interest  in  dbars 


P*  = 

Z*  =  depth  in  meters  at  pressure  P*. 

a  =  in  situ  specific  volume,  a  function  of  in 
situ  temperature  (T),  salinity  (S)  and 
pressure  (P). 

g(P)  *  gravitational  acceleration,  a  function  of 
latitude  and  depth.  For  calculation  of  g 
assume  depth  in  meters  =  pressure  in  dbars. 

Second,  determine  values  of  all  parameters  (except 
pressure)  at  the  extended  standard  levels  (see  Table  3.1). 
These  levels  come  from  recommendations  made  by  A.  F.  Amos 
(personal  communication)  modified  by  increasing  the  maximum 
increment  from  100  m  to  200  m.  Interpolate  when  necessary. 
If  the  standard  levels  are  within  2  m  of  the  observations 
consider  the  standard  level  values  observed,  otherwise  mark 
them  interpolated.  Use  the  same  3-point  Lagrange  interpo¬ 
lation  scheme  presently  in  force  in  the  Serial  Depth  Data 
System,  with  the  same  exceptions. 

After  the  standard  values  have  been  selected 
then  test  the  original  profile  against  linear  fits  between 
the  standard  levels.  As  with  the  ICES  compression,  if  the 
difference  exceeds  a  given  tolerence,  say  .02°C  and/or 
.02  °/oo,  add  a  level  at  the  depth  of  maximum  difference. 
Refit  lines  between  the  new  point  and  the  adjacent  standard 
levels  and  continue  comparing  against  the  original  profile. 
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Table  3.1 

101  EXTENDED  STANDARD  LEVELS  (meters) 


rement:  2 

5 

10 

20 

25 

50 

100 

200 

200 

0 

35 

60 

120 

225 

550 

1100 

2200 

6200 

2 

40 

70 

140 

250 

600 

1200 

2400 

6400 

4 

45 

80 

160 

275 

650 

1300 

2600 

6600 

6 

50 

90 

180 

300 

700 

1400 

2800 

6800 

8 

100 

200 

325 

750 

1500 

3000 

7000 

10 

350 

800 

1600 

3200 

7200 

12 

375 

850 

1700 

3400 

7400 

14 

400 

900 

1800 

3600 

7600 

16 

425 

950 

1900 

3800 

7800 

18 

450 

1000 

2000 

4000 

8000 

20 

475 

4200 

8200 

22 

500 

4400 

8400 

24 

4600 

8600 

26 

4800 

8800 

28 

5000 

9000 

30 

5200 

9200 

5400 

9400 

5600 

9600 

5800 

9800 

6000 
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This  method  should  keep  the  number  of  points 
under  100  except  for  very  variable  and  very  deep  profiles. 
It  constitutes  an  improvement  over  the  present  version  by 
eliminating  the  occurrence  of  an  inflection  point  so  close 
to  a  standard  level  as  to  be  redundant.  It  also  keeps  the 
routine  rapid  and  makes  the  inflection  points  much  less 
sensitive  to  the  starting  point  of  the  search. 

Write  the  compressed  station  on  a  tape  for  reading 
by  the  Serial  Depth  Data  System.  Though  frequent  occurrence 
of  compressed  stations  with  more  than  100  points  is  bulky, 
up  to  160  levels  can  be  accommodated  (I.  Perlroth,  NODC, 
personal  communication).  If  more  levels  than  this  are 
selected,  the  inflection  point  criteria  will  have  to  be 
slackened . 

3.6  CONCLUSION 

An  outline  has  been  presented  which  specifies 
the  components  that  belong  in  a  system  to  archive,  control 
and  disseminate  historical  stratification  data  using  STDs 
and  CTDs.  Further  descriptions  can  only  be  generated  during 
the  programming  necessary  to  implement  the  system.  It  is 
envisioned  that  improvements  may  still  be  made  to  the 
components  described  in  this  report.  These  improvements, 
like  the  further  descriptions,  are  appropriate  during  the 
implementation  phase.  It  is.  not  envisioned  that  any  sub¬ 
stantial  changes  to  the  system  described  herein  are  re¬ 
quired  . 

Oceanographic  community  impatience  for  an  his¬ 
torical  STD/CTD  archive  dictates  that  a  decision  on  the 
suitability  of  this  system  and  its  subsequent  implementation 
be  undertaken  rapidly. 
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Appendix  A 

GF3  Exchange  Format  for 
STD/CTD  Data 


INTRODUCTION 


A.  1 

This  manual  for  the  implementation  of  the  GF3 
system  for  STD/CTD  data  exchange  relies  heavily  on  the 
original  GF3  manual  (Intergovernmental  Oceanographic  Com¬ 
mission,  1979)  and  will  repeat  entire  sections.  This  is 
done  so  that  the  present  writing  can  stand  alone.  STD/CTD 
specific  paragraphs  and  tables  will  be  marked  by  a  "$". 

The  IOC  General  Format  3  (GF3)  is  a  system  for 
formatting  oceanographic  data  onto  magnetic  tape  for  inter¬ 
national  exchange  among  data  centers.  Although  it  has  not 
been  intended  or  recommended  for  internal  use  in  the  cen¬ 
ters,  it  may  nevertheless  be  found  suitable  for  archival  of 
certain  data,  e.g.,  project  data  sets.  In  fact,  in  spite  of 
its  apparent  complexity,  it  can  be  easily  used  by  single 
scientific  users,  small  institutions,  or  large  data  handling 
centers.  Testing  has  shown  it- to  be  sufficiently  general  to 
encode  virtually  any  type  of  digital  oceanographic  data 
including  physical,  chemical,  biological,  geological, 
meteorological  and  geophysical  data.  Being  multi-discipli¬ 
nary  in  nature,  it  also  may  well  find  use  in  environmental 
studies  outside  oceanography.  Data  can  be  written  or 
retrieved  with  simple,  rather  short  programs,  and  fully 
automated  if  so  desired. 

GF3  is  not  a  wholly-new  system;  rather,  it  evolved 
from  the  format  originally  developed  for  use  in-  the  GATE 
project,  and  that  was  subsequently  modified  by  IODE  to 
become  the  GF2  format.  GF2  suffered  from  three  main  prob¬ 
lems:  (a)  a  structure  that  was  too  rigid  and  limited  to 
cover  all  types  of  oceanographic  data  effectively,  (b)  a 
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restricted  capacity  for  the  inclusion  of  plain  language 
documentation,  and  (c)  an  excess  of  fixed  format  fields  that 
were  either  rarely  used  or  could  just  as  effectively  have 
been  included  as  plain  language  comments  or  user-defined 
fields.  However,  as  GF2  had  a  certain  degree  of  acceptance 
and  was  in  use  at  some  institutes  and  data  centers,  GF3  was 
built  from  its  framework.  Indeed,  it  is  possible  to  create 
GF3  files  that  simulate  GF2  files,  and  files  can  be  con¬ 
verted  from  GF2  to  GF3  with  minimal  loss  of  information. 

It  has  been  emphasized  in  the  preceding  paragraphs 
that  GF3  is  a  system  rather  than  strictly  a  format  in  the 
conventional  sense.  As  a  system  it  allows  the  user  a  number 
of  ways  of  organizing  his  data  such  that  whichever  way  he 
chooses,  the  data  fit  into  GF3.  Furthermore,  provision  is 
made  for  the  user  to  describe,  on  the  same  magnetic  tape 
that  carries  the  data,  the  exact  format  he  has  selected  and 
all  codes  he  has  used,  as  well  as  ample  space  for  plain 
language  documentation. 

This  flexibility  is  obtained  from  the  three  major 
attributes  of  the  system.  First,  GF3  recognizes  that  most 
data  sets  are  organized  in  a  hierarchy,  i.e.  the  volume  of 
information  increases  with  depth  in  the  hierarchy.  Like¬ 
wise,  the  information  at  the  top  pertains  to  the  whole  set, 
and  information  in  middle  levels  serves  to  group  variously 
together  what  falls  below  it.  In  GF3  terminology,  the 
bottom  of  the  hierarchy  comprises  data  cycles;  the  middle 
levels  group  the  data  cycles  into  series;  and  at  the  top, 
the  series  are  grouped  into  files.  $  For  STD/CTD  appli¬ 
cations  the  data  cycle  contains  the  observations  made  at  a 
single  level;  the  GF3  series  contains  all  the  data  pertinent 
to  a  single  station;  and  the  GF3  file  contains  all  the 
stations  in  a  single  cruise. 


Secondly,  GF3  recognizes  that  the  need  for  format 
uniformity  is  greatest  at  the  top  of  the  hierarchy  and  that 
flexibility  must  increase  in  descent.  Consequently,  there 
are  several  mandatory  fields  at  the  file  level,  and  at  the 
series  level,  and  virtually  none  below.  Thus,  the  user 
preparing  data  for  GF3  is  given  flexibility  in  organizing 
and  writing  his  data,  and  the  user  reading  data  in  GF3  can 
expect  the  particular  high-level  information  he  needs  to 
understand  the  data  he  has  received.  $  For  STD/CTD  applica¬ 
tions  the  user  retains  flexibility  only  in  the  number  and 
types  of  parameters  that  constitute  a  data  cyle.  Station 
information  must  be  supplied  in  a  given  format. 

Thirdly,  GF3  recognizes  that  its  magnetic  tapes 
must  be  easily  read  by  relatively  simple  computer  programs. 
At  each  hierarchy  level  in  the  data  set,  GF3  provides  for 
information  to  be  recorded  that  explains  the  formats  the 
user  has  chosen  for  the  descendant  levels.  This  facility, 
combined  with  the  liberal  use  of  plain  language  text,  means 
that  a  GF3  data  set  on  magnetic  tape  is  both  self-describing 
and  self-documenting.  The  user  reading  the  data  tape  need 
only  know  that  it  is  in  the  GF3  system.  More  simple,  less 
general,  programs  can  be  used  to  read  the  STD/CTD  implemen¬ 
tation  of  the  GF3  tapes. 
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STRUCTURAL  SPECIFICATION 


A. 2 


The  best  understanding  of  the  GF3  system  is  gained 
by  examining  the  overall  tape  features  in  terms  of  files, 
followed  by  an  explanation  of  the  build-up  of  the  files 
themselves  from  the  allowed  record  types.  Finally  the 
design  of  the  record  types  will  be  discussed.  Detailed 
layout  of  the  fields  within  the  records  is  found  in  the  next 
section. 


A. 2.1  Magnetic  Tape  Physical  Specifications 

A. 2. 1.1  GF3  is  a  character  oriented  format  for  use  with 
digital  magnetic  tapes.  Such  tapes  should  be  0.5  inch  (12.7 
mm)  wide  with  a  maximum  reel  diameter  of  10.5  inches  (266.7 
mm)  and  a  maximum  tape  length  of  2,400  feet  (732  m) . 

A. 2. 1.2  Unless  agreed  otherwise  between  exchanging  par¬ 
ties,  tapes  should  be  either  7-track,  556  b.p.i.  (bytes  per 
inch),  even  parity  or  9-track,  800  b.p.i.,  odd  parity  and 
written  by  Non-Return-to-Zero  (NRZI)  encoding. 

A. 2. 1.3  Unless  agreed  otherwise  between  exchanging  parties 
7-track  tapes  should  be  written  in  BCD  (Binary  Coded  Deci¬ 
mal)  and  9-track  tapes  in  ASCII,  EBCDIC  (Extended  BCD)  or 
Minsk-32  code.  GF3  includes  a  translation  table  for  use  in 
the  conversion  of  character  codes. 

A. 2. 1.4  The  GF3  character  set  is  restricted  to  the  Latin 
capital  letters,  the  decimal  numerals  and  those  special 
characters  which  are  common  to  all  four  standard  codes  (BCD, 
ASCII,  EBCDIC  and  Minsk-32).  (See  GF3  Code  Table  (2)). 


A. 2. 1.5  All  GF3  physical  records  (blocks)  on  tape  are  of 
a  fixed  length  of  1920  bytes  (characters)  padded  with  blanks 
or  nines  (9's)  where  necessary  to  make  up  the  length.  These 
physical  records  are  separated  by  inter-record  gaps  (IRG) 
and  are  organized  into  files.  Each  file  is  terminated  by  a 
single  End  of  File  (EOF)  Mark  (sometimes  called  a  tape  mark) 
except  for  the  last  file  on  each  tape  which  is  terminated  by 
two  EOF  marks.  Other  uses  of  EOF  marks  are  prohibited. 

A. 2. 1.6  Except  for  the  EOF  mark  the  use  of  other  system 
labels  and  blocks  is  prohibited.  The  EOF  mark  itself  is  a 
single  byte  block  consisting  of  the  Device  Control  Charac¬ 
ter,  DC3  ("1"  bits  in  tracks  2,  3  and  8  only)  on  9-track 
tapes  and  the  octal  characters  "17"  on  7-track  tapes. 
Should  EOFs  other  than  these  come  into  use  they  will  be 
added  to  GF3  Code  Table  (2). 

A. 2. 2  GF3  Logical  Tape  Structure 


A. 2. 2.1  Four  types  of  files  are  recognized: 

Test  File 
Tape  Header  File 
Data  File 

Tape  Terminator  File 

A. 2. 2. 2  Each  GF3  tape  must  begin  with  a  file  of  Test 

Records  terminated  by  an  EOF  mark  and  followed  by  a  Tape 
Header  File  containing  a  Tape  Header  Record  as  its  first 
record.  Following  the  Tape  Header  File  are  inserted  as  many 
individual  Data  Files  as  are  required  before  the  tape  itself 
is  finally  terminated  by  a  Tape  Terminator  File  consisting 
solely  of  an  End  of  Tape  Record  followed  by  two  EOF  marks. 
The  tape  structure  is  diagrammed  in  Figure  1. 
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Figure  A-l :  GF3  TAPE  STRUCTURE 
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NEXT  DATA  FILE 


A. 2. 2. 3  If  a  Daia  File  is  loo  long  to  fit  onto  one 
magnetic  tape,  it  can  be  continued  on  further  reels.  The 
Tape  Header  File  contains  information  to  show  if  the  Data 
File  is  the  continuation  of  a  Data  File  on  a  preceding  tape, 
and  the  Tape  Terminator  File  shows  whether  the  Data  File  is 
continued  on  a  following  tape. 

A. 2. 2. 4  Following  the  discussions  of  files  and  records 
in  Sections  2.3  and  2.4,  the  organization  and  ordering  of 
GF3  records  within  the  file  structure  of  GF3  is  shown  in 
Figure  A. 2  for  STD/CTD  tapes. 

A. 2. 3  GF3  File  Structure 


Each  of  the  four  types  of  files  identified 
within  GF3  have  a  well-defined  structure  of  allowable  record 
types.  $  The  allowable  types  for  STD/CTD  files  are  a  subset 
of  the  GF3  allowable  types. 

A. 2. 3.1  Test  File 

The  Test  File  is  a  special  file  containing 
sufficient  physical  records  (Test  Records)  to  occupy  about  2 
meters  at  the  beginning  of  the  tape.  Each  Test  Record 
should  contain  1920  test  characters  defined  as  all  binary 
l's.  The  Test  File  not  only  provides  useful  protection  for 
the  beginning  of  the  tape  against  mechanical  damage  but  also 
allows  checks  on  the  relative  alignment  of  tape  read  beads 
between  the  parties  involved  in  data  exchange. 

A. 2. 3. 2  Tape  Header  File 

$  The  Tape  Header  File  comprises  a  Tape  Header 
Record  followed  by  Plain  Language  Records,  and  a  Series 
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Header  Definition  Record.  The  information  in  the  Tape 
Header  File  pertains  to  the  entire  tape. 

A. 2. 3. 3  Data  File 

$  The  Data  File  comprises  one  File  Header  Record 
and  several  Series  Header  Records  (each  associated  with  a 
Data  Cycle  Definition  Record),  several  Plain  Language 
Records  indicating  collecting  and  processing  procedures,  and 
several  Data  Cycle  Records  containing  the  STD/CTD  measure¬ 
ments. 

A. 2. 3. 4  Tape  Terminator  File 

The  Tape  Terminator  File  appears  only  as  the 
last  file  on  a  tape,  and  all  GF3  tapes  must  end  with  a  Tape 
Terminator  File.  This  file  comprises  only  an  End-of-Tape 
Record. 

A . 2 . 4  $  Record  Structure 

All  physical  records  consist  of  1920  charac¬ 
ters  which  can  'be  divided  logically  into  24  cards  of  80 
characters  each.  The  records  are  defined  in  general  below 
and  in  more  detail  in  a  later  section.  The  arrangement  of 
these  records  on  the  tape  within  the  file  structure  is 
illustrated  in  Figure  A. 2. 

A. 2. 4.1  Test  Record 

The  Test  Record  comprises  1920  characters 
all  set  to  the  hexadecimal  "FF".  This  is  equivalent  to 


GF3-TYPE  TAPES  FOR 
STD/CTD  DATA  EXCHANGE 


TEST  RECORD 


TEST  RECORD 


source  &  description 
of  data  on  tape  and 
dace  tape  was  created 


PLAIN  LANGUAGE 
RECORD 


complete  references  for  algorithms 
cited  in  station  documentation 


FILE  HEADER 
RECORD 


defines  variables  in  station 
header  besides  the  GF3  stan¬ 
dard  station  identifiers  & 
time  &  space  coordinates 


defines  the  time,  space 
limits  of  the  data  in 
the  file  in  standard 
GF3  format 


DATA  CYCLE 
DEFINITION  RECORD 


defines  which  vari¬ 
ables  are  in  each 
data  cycle  for  the 
station  that  follows 


DATA  CYCLE 
RECORD 


SERIES  HEADER 
RECORD 


PLAIN  LANGUAGE 
RECORD 


defines  the  time  & 
space  coordinates  of 
the  station  identi¬ 
fiers  in  standard  GF3 
format  &  values  of 
variables  defined  above 
in  the  series  header 
definition  record 


DATA  CYCLE 
RECORD 


PLAIN  LANGUAGE 
RECORD 


profiled  data  for  this  station  in  format 
described  in  data  cycle  definition  record 
for  this  station 


Figure  A-2 


specifies  in  a  fixed  manner  the 
collection  &  processing  techniques 


contains  continuation  informa¬ 
tion  if  data  is  continued  on 
another  tape 


setting  all  binary  bits  to  "1".  The  Test  Record  is  used 
only  in  the  Test  File  at  the  beginning  of  a  GF3  tape.  The 
Test  File  must  contain  sufficient  physical  records  to  occupy 
about  2  meters  at  the  beginning  of  the  tape.  The  Test  File 
provides  useful  protection  for  the  beginning  of  the  tape 
against  mechanical  damage  and  allows  checks  on  the  relative 
alignment  of  tape  read  heads  between  the  parties  involved  in 
the  data  exchange. 

A. 2.4.2  Tape  Header  Record  (Record  ID  =  1) 

The  Tape  Header  Record  appears  only  once  per 
tape  at  the  beginning  of  a  Tape  Header  File.  The  first  two 
card  images  in  a  Tape  Header  Record  contain  information  on 
the  creation  of  the  tape  such  as  the  tape  identifier,  date 
and  time  of  creation,  the  institution  responsible  for  its 
creation,  and  the  type  of  computer  used,  together  with  tape 
sequencing  information  if  the  ■  data  reside  on  more  than  one 
tape.  The  third  card  image  contains  the  standard  GF3 
Character  Set  as  written  by  the  particular  computer  gener¬ 
ating  the  tape.  This  is  necessary  for  producing  a  decoding 
table  which  is  useful  in  translating  characters  stored  with 
unusual  codes  or  with  unknown  application  of  the  parity 
bit.  The  remaining  card  images  are  used  for  plain  language 
comments  identifying  the  data  as  STD  and/or  CTD  data  and 
listing  the  cruises  on  the  tape  (one  cruise  per  file). 
Other  comments  relating  to  the  tape  as  a  whole  can  be 
inserted  if  room  allows. 


A. 2. 4. 3 


Plain  Language  Records  (Record  ID  =  0) 


Except  for  the  first  two  characters  and  last 
three  characters  on  each  card  image  the  Plain  Language 
Records  are  available  for  free  format  text  in  the  GF3 
system. 


For  STD/CTD  data  exchange  the  first  few  Plain 
Language  Records  following  the  Tape  Header  Record  are 
reserved  for  listing  the  complete  references  for  algorithms 
cited  in  the  data  processing  documentation  portion  of  the 
station  data.  Other  comments  on  the  tape  as  a  whole  may  be 
made  in  following  Plain  Language  Records. 

For  STD/CTD  data  exchange  Plain  Language 
Records  are  also  used  following  the  header  record  for  each 
station.  In  this  use  the  first  several  Plain  Language 
Records  are  not  free  format  but  must  contain  specific  items 
of  information  in  specific  positions.  These  items  include 
descriptions  of  pertinent  collection  and  processing  proce¬ 
dures  that  apply  for  that  particular  station.  (Although 
these  collection  and  processing  procedures  are  generally 
applicable  for  an  entire  cruise,  the  information  is  repeated 
so  that  each  station  may  be  extracted  and  used  indepen¬ 
dently). 

A. 2. 4. 4  Series  Header  Definition  Record  (Record  ID  ■  3) 

Each  STD/CTD  station  constitutes  one  "series" 
in  the  GF3  terminology.  Each  file  is  made  up  of  several 
stations  linked  by  a  common  cruise  or  location  or  time.  For 
data  submission  only  groupings  by  cruise  are  acceptable. 


A-ll 


I 


t 


The  Series  Header  Definition  Record  defines  the  contents  of 
those  card  images  in  the  Series  (station)  Header  Record  that 
are  not  determined  by  the  GF3  standard  formats.  These 
contents  have  been  fixed  for  STD/CTD  data  exchange.  The 
Series  Header  Definition  Record  is  written  once  per  tape,  as 
part  of  the  Tape  Header  File,  because  all  station  headers 
are  to  be  in  the  same  format  throughout  the  tape.  The 
Series  Header  Definition  Record  describes  the  format  for 
storing  such  information  as:  whether  the  data  is  from  an 
uptrace  or  a  downtrace;  water  color  and  transparency;  wave 
direction,  period  and  height;  sea  state;  wind  force,  direc¬ 
tion  and  speed;  barometric  pressure,  dry  bulb  temperature; 
wet  bulb  temperature;  weather;  cloud  type  and  cloud  amount 
codes;  drop  rates;  ship  roll;  and  results  of  quality  control 
tests.  The  Series  Header  Definition  Record  also  gives  the 
parameter  names  and  format  for  bottle  ("classical")  measure¬ 
ments  taken  at  the  STD/CTD  station.  Note,  data  for  all 
these  parameters  are  stored  in  the  Series  Header  Record  - 
there  are  no  data  in  the  Series  Header  Definition  Record. 
The  Series  Header  Definition  Record  merely  contains  names 
and  formats  for  the  data. 

A. 2.4.5  File  Header  Record  (Record  ID  =  5) 

All  STD/CTD  stations  from  a  single  cru-lse 
should  be  grouped  into  one  file  for  data  submission.  The 
File  Header  Record  contains  the  latitude,  longitude,  date 
and  time  limits  for  the  cruise  contained  in  the  file.  It 
also  names  the  platform,  the  instruments  used  and  the  number 
of  stations  in  the  cruise.  This  information  is  stored  in 
the  first  5  card  images  of  the  File  Header  Record  in  a 
standard  GF3  format.  The  File  Header  Record  is  the  first 
record  in  the  data  file. 
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A  .  2 . 4 . 6 


Data  Cycle  Definition  Record  (Record  ID  =  4) 


The  basic  STD/CTD  data  cycle  contains  pressure, 
temperature  and  conductivity  measurements,  and  the  derived 
parameter:  salinity.  Other  parameters  might  also  be 
reported  (e.g.,  time,  sound  velocity,  water  velocity  etc.) 
so  a  Data  Cycle  Definition  Record  is  necessary  to  indicate 
which  parameters  are  reported.  Though  this  information  is 
usually  constant  throughout  a  cruise,  the  information  is 
repeated  so  that,  once  again,  each  station  can  be  retrieved 
from  the  cruise  file  independently.  Flag  bytes  should  also 
be  used  to  indicate  questionable  or  interpolated  elements  in 
a  data  cycle.  The  presence  of  such  flag  bytes  must  be 
indicated  in  the  Data  Cycle  Definition  Record.  To  repeat, 
there  are  no  data  in  the  Data  Cycle  Definition  Record,  only 
parameter  names  and  format . 

A. 2. 4. 7  Series  Header  Record  (Record  ID  =  6) 

This  record  occurs  once  per  station  and  contains 
station  location,  time  and  identification  information  in  a 
standard  GF3  format.  it  also  includes  non-STD/CTD  data  such 
as  meteorological  and  surface  observations  and  "classical" 
measurements,  all  defined  in  the  Series  Header  Definition 
Record  which  is  described  above. 

The  Series  Header  Record  is  followed  by  several 
Plain  Language  Records  which  indicate  the  collection  and 
processing  procedures  whereby  the  STD/CTD  data  were  pro¬ 
duced  . 
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A. 2. 4. 8 


Data  Cycle  Record  (Record  ID  =  7) 


Many  of  these  records  follow  the  Plain  Language 
Records  for  each  station.  Each  Data  Cycle  Record  contains 
an  integral  number  of  data  cycles  with  parameters  in  a  format 
described  in  the  Data  Cycle  Definition  Record  at  the  begin¬ 
ning  of  the  station.  In  general,  these  records  would 
constitute  the  largest  portion  of  the  records  on  tape. 

A. 2. 4. 9  End  of  Tape  Record  (Record  ID  =  8) 

This  Record  appears  only  once  per  tape  at  the 
end  of  a  tape.  The  End  of  Tape  Record  is  the  only  record  in 
the  last  file  on  the  tape.  It  indicates  whether  the  data 
are  continued  on  another  tape.  In  addition  the  End  of  Tape 
Record  may  contain  comments  concerning  the  tape. 
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A.  3 


Detailed  Specification  for  Record  Contents 


In  this  section,  specifications  are  given  for 
each  type  of  record  described  in  the  previous  section, 
except  the  Test  Record  which  is  adequately  specified 
there.  The  record  specifications  are  presented  in  Tabular 
form,  and  each  field  is  described  under  four  headings: 


CARD  NO.  -  Sequence  number  within  the  record  of 

the  card  image  containing  the  field. 


CARD  BYTE  NO.  -  Position  occupied  by  the  field  within 

the  card  image  expressed  in  bytes 
(characters)  relative  to  the  begin¬ 
ning  of  the  card  image. 


NO.  OF  BYTES  -  Length  of  the  field  in  bytes  (char¬ 
acters). 


DESCRIPTION 
OF  FIELD 
AND  COMMENTS 


Instructions  on  what  information 
to  insert  in  the  field  and  the 
manner  in  which  to  do  it.  Certain 
information  is  inserted  via  codes. 
Tables  of  these  codes  are  included 
at  the  end  of  the  appendix.  Refer¬ 
ence  to  the  Tables  are  made  under- 
this  heading. 


Data  coding  forms  that  summarize  the  information  in  the 
following  sections  are  included.  All  numeric  entries  are 
made  as  integers,  the  placement  of  the  decimal  is  either 
inferred  or  entered  separately.  Entries  in  the  Plain 
Language  Records  are  typically  alphanumeric. 
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A. 3.1  PLAIN  LANGUAGE  RECOFID 
RECORD  ID  0 


Number 
of  Bytes 
in  Field 


Description  of  Field  and  Comments 

"0"  Plain  language  record  identifier  (set  this 
byte  to  ”0"). 

Record  identifier  of  the  next  record. 

Plain  language  cannents  or  description. 

"1"  Chrd  sequence  number  (set  these  bytes  to 
”001”). 

Bytes  2  to  77  on  each  card  may  be  used  for  plain 
language  conments  or  description  -  on  each  card 
used  in  this  way,  byte  1  contains  "0"  the  record 
identifier  and  bytes  78  -  30  contain  the  card 
sequence  number  (002  -  024). 

Note:  Plain  language  cannents  or  description  may 
be  continued  on  succeeding  Plain  Language  Records 
if  necessary  using  card  sequence  numbers  025  -  048, 
049  -  072,  etc.-  each  record  used  in  this  way  should 
be  formatted  as  above  and  the  2nd  byte  of  the  record 
should  contain  the  record  identifier  of  the  next 
record. 

Any  cards  in  a  Plain  Language  Record  not  completed 
should  be  filled  with  blanks  except  for  bytes  1  and 
78  -  80.  For  the  Plain  Language  Records  which  follow 
the  Tape  Header  Record,  the  comments  must  contain  a 
complete  reference  list  for  processing  and  collecting 
algorithms  used  on  the  data. 


GF3  Coding  Form  A.  PLAIN  LANGUAGE  RECORD 


DgBanDnnngignnngnnagaBBgnnBnnanggggMEEBnBBmBnmBBBBBBEniBgBEcqBBnEgaBEBnBiB 


A. 3.2  TAPE  HEADER  RECORD 
RECORD  ID  1 


Card  Number 

Card  Byte  of  Bytes  Description  of  Field  and  Comments 

No.  No.  in  Field 


1 

1 

"1"  record  identifier 

2 

1 

Record  identifier  of  the  next  record. 

3 

4 

Unassigned  -  leave  blank. 

7 

2 

IOC  Country  code  of  the  country  of  the  institution 
that  wrote  (originated)  this  tape.  Table  1. 

9 

1 

Enter  "9"  to  indicate  that  following  code  is  National. 

10 

3 

National  Institution  code  (if  available)  of  the  insti¬ 
tute  or  data  center  that  wrote  (originated)  this  tape. 

13 

12 

Tape  name  or  number  -  unique  to  institution  that  wrote 
(originated)  this  tape. 

25 

5 

Unassigned  -  leave  blank. 

30 

12 

Name  or  number  of  preceding  tape  (if  file  continued 
from  another  tape).  (Blank  if  not  a  continuation 
tape). 

42 

18 

Country  -  plain  language  -  name  of  country  of  the 
institution  that  wrote  (originated)  this  tape 

60 

18 

Institution  -  plain  language  -  name  of  the  institute 
or  data  center  that  wrote  (originated)  this  tape. 

78 

3 

Card  sequence  number  "001" 

1 

1 

"1"  record  identifier 

2-7 

6 

Date  (YYMMDD)  that  this  tape  was  written  by  above 
institution. 

8 

6 

Date  (YYMMDD)  that  first  version  of  the  data  on 
this  tape  was  written  by  above  institution  (same  as 
bytes  82  -  87  unless  previous  versions  were  in  error 
or  lost,  etc.). 

14 

6 

Date  (YYMMDD)  that  this  tape  was  received  at  receiv- 

ing  data  center  or  institute  (must  be  set  to  9's  when 
tape  is  written  -  can  only  be  "filled-in"  if  receiv¬ 
ing  institution  copies  the  tape). 
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A. 3. 2  T.APE  HEADER  RECORD  (Continued) 
RECORD  ID  1 


Number 
of  Bytes 
in  Field 


Description  of  Field  and  Comments 


Date  (YYMMDD)  that  first  version  of  this  tape 
was  received  (must  be  set  to  9’s  when  tape  is  written 
-  can  only  be  "filled-in"  if  receiving  institution 
copies  the  tape)  (same  as  bytes  14  -  19  unless 
updated) 

Type  of  computer  used  to  write  this  tape  (PLAIN 
LANGUAGE)  -  Manufacturers  Model 

Acronym  of  the  format  used  -  set  these  bytes  to 
"GF3.1" 

Unassigned  -  leave  blank 
Card  sequence  number  "002" 

"1"  record  identifier 

Translation  table  (Table  2)  containing  GF3  character 
set 


Unassigned  -  leave  blank 

Record  size  in  bytes  (set  these  bytes  to  "1920") 

Card  sequence  number  "3"  (set  these  bytes  to  "003") 

Bytes  2  to  77  on  each  card  may  be  used  for  plain 
language  comments  or  description  -  on  each  card  byte 
1  contains  "1"  the  record  identifier,  and  bytes  78  - 
80  contain  the  card  sequence  number  (004  -  024) 

Note:  Plain  language  coranents  or  description  may 
be  continued  on  succeeding  Plain  Language  Records  if 
necessary  using  card  sequence  numbers  025  -  048, 

049  -  072,  etc. 


A.  3'. 3  STATION  IIEADFR  DEFINITION  RECORD  *1 
RECORD  ID  3 


Card  Number 

Card  Byte  of  Bytes  Description  of  Field  and  Comnents 

No. _ No. _ in  Field _ 

11  1  "3”  identifies  this  record  as  a  series  (station) 

header  definition  record,  i.e.,  is  used  to  define 
non-GF3  areas  of  the  station  header  record. 

2  1  Record  ID  #  of  next  record  on  tape.  $  It  is  also 

a  station  header  definition  record,  so  set  to  "3". 

3  3  $  "31"  indicates  the  number  of  variables  reported 

once  in  the  non-GF3  area  of  the  station  header  record. 

6  3  $  "10"  indicates  the  number  of  variables  reported 

repeatedly  in  the  non-GF3  area  of  the  station  header 
record. 

9  1  $  "I"  indicates  that  data  are  written  in  the  non-GF3 

area  of  the  station  header  record  as  integers  exclu¬ 
sively. 

10  8  Blank. 

18  80  Part  of  FORMAT  for  reading  data  in  non-GF 3  area  of 

the  station  header  record.  $  The  contents  of  this 
field  are  fixed  for  STD/CTD  users.  This  field  is  for 
the  benefit  of  GF3  users  not  acquainted  with  the 
STD/CTD  implementation.  See  attached  form  for 
contents. 

78  3  "001"  card  sequence  number. 

211  "3"  record  ID. 

2  16  Blank. 

18  60  More  of  format  for  reading  data  in  non  GF3  area  of 

the  station  header  record.  $  Contents  are  fixed  for 
STD/CTD  users.  See  attached  form  for  contents. 

78  3  "002"  card  sequence  number. 

311  "3"  card  sequence  number. 

2  76  Blank. 

78  3  "003"  card  sequence  number. 


Card 

No. 


4-24 


1 


2-3 


4-22 


23-24 


A. 3. 3  STATION  HEADER  DEFINITION  RECORD  #1  Continued 
RECORD  ID  3 


Card  Number 

Byte  of  Bytes  Description  of  Field  and  Comments 

No.  in  Field 


1  1  "3". 

2  76  $  Contents  specified.  Identifies  header  param¬ 

eter,  units,  default  value  and  scaling  factors. 
See  attached  form  for  contents. 

78  3  Card  sequence  number  ’’004’’  to  "024". 


STATION  HEADER  DEFINITION  RECORD  #2 


1 

2 

3 

78 

1 

2 

78 

1 

2 

78 

1 

2 

78 


1  "3"  record  ID. 

1  Record  ID  of  next  record  on  tape  $  it  will  be  a 

file  header  record,  so  set  to  "5". 

75  Blank. 

3  "025"  card  sequence  number. 

1  "3"  record  ID. 

76  Blank. 

3  "026"  -  "027"  card  sequence  number. 

1  "3"  record  ID. 

76  $  Contents  specified.  More  header  parameters  and 

classicially  measured  parameters. 

3  "028"  -  "046"  card  sequence  number. 

1  "3"  record  ID. 

76  Blank'. 

3  "047."  -  "048"  card  sequence  number. 
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DEFINITION 


CODtO  IV 


A. 3.4  FILE  (CRUISE)  HEADER  RECORD 
RECORD  ID  5 


Card  Number 

Card  Byte  of  Bytes  Description  of  Field  and  Conraents 

No.  No.  in  Field 


1  1 


1  '*5"  record  identifier. 


2 

3 

12 


14 


1  Record . identifier  of  the  next  record  ($  set  to  "4"). 

9  Project  name. 

2  IOC  Country  Code  for  the  country  containing  the 
institution  collecting  the  data  in  this  file 
(i.e.  the  original  source  of  data),  Table  1. 

1  Enter  "9''  to  indicate  that  following  code  is 

National . 


15 


18 

36 

54 

60 

66 

78 


3  National  Institution  Code  (if  available)  of  the 

institute  collecting  the  data  in  this  file  (i.e., 
original  source  of  data). 

18  Country  -  plain  language  )  original  source  of  data  as 

18  Institute  -  plain  language)  coded  in  bytes  12  -  17. 

6  Date  (YYMMDD)  this  version  of  the  file  was 

created  (YY  =  Year,  MM  =  Month,  DD  =  Day). 

6  Time  (HHMMSS)  this  version  of  the  file  was 

created  (HH  =  Hours,  MM  =  Minutes,  SS  =  Seconds). 

12  Processing  Number  or  Identifier  assigned  to  this  file 

by  data  center. 

3  Card  Sequence  Number  "001". 

1  "5"  record  identifier. 


2 


2  Platform  type  code  (primary  platform).  Table  3. 


4 


8  Platform  type  -  plain  language  (e.g.,  Ship,  Buoy, 

Aircraft,  Float,  etc.). 


12 


1  Meaning  of  following  bytes,  1  -  ITU,  2  *  WM0/I0C, 

9  »  National  or  local  identifier. 


13  9  Specific  Platform  Code  -  e.g.,  ship  or  aircraft 

call  sign,  mooring  or  buoy  identifier,  etc.,  Table 
4. 


A. 3.4  FILE  (CRUISE)  HEADER  RECORD  Continued 
RECORD  ID  5 


T 


Card 

No. 

Card 

Byte 

No. 

Number 
of  Bytes 
in  Field 

Description  of  Field  and  Conments 

22 

22 

Platform  name  -  plain  language  -  commonly  used 
name  e.g.,  ship  name. 

44 

10 

Reference  No. /Identifier  assigned  by  the  Insti¬ 
tution  originating  the  data  to  the  Cruise  of  the 
platform,  during  which  the  data  was  collected. 

54 

12 

Date/Time  at  start  of  cruise  expressed  as 

CCYYMMDDHHMM. 

66 

12 

Date/Time  at  end  of  cruise  expressed  as  CCYYMMDDHHMM 

0C  =  Century,  YY  =  Year,  MM  =  Month,  DD  =  Day,  HH  =  Hours, 

MM  =  Minutes.  Enter  to  appropriate  precision  leaving 
remaining  digits  blank. 

78 

3 

Card  Sequence  Number  "002’’. 

3 

1 

Secondary  platform  information  in  same  format  as 
card  2,  for  example  a  mooring  may 
be  the  primary  platform,  in  which  case  it  is 
relevant  to  specify  the  ship  setting  that  mooring. 

78 

3 

Card  Sequence  Number  "003". 

4 

1 

1 

"5"  record  identifier. 

2 

14 

Date/time  of  the  earliest  observation  in  the  file. 

Expressed  as  CCYYMMDDHHMMSS  where  CC  =  Century,  YY 
=  Year,  MM  =  Month,  IX)  =  Day,  HH  =  Hours,  MM  = 

Minutes  and  SS  =  Seconds.  Expressed  in  GMT  and 
entered  to  the  appropriate  precision  leaving 
remaining  digits  blank. 

16 

14 

Date/time  of  the  latest  observation  in  the  file. 

Expressed  as  for  preceeding  byte.  j 

30 

6,1 

Latitude  expressed  as  DDMMHH,  (N/S)  entered  only  j 
if  all  observations  in  this  file  are  collected  at  -! 
the  same  position  -  otherwise  fill  with  9's.  ] 

37 

7,1 

i 

Longitude  expressed  as  DDDMMHH,  (E/W)  entered  only  j 
if  all  observations  in  this  file  are  collected  at  i 
the  same  position  -  otherwise  fill  with  0's.  ] 

A. 3.4  FILE  (CRUISE)  HEADER  RECORD  Continued 

RECORD  ID  5 


Card  Number 

Card  Byte  of  Bytes  Description  of  Field  and  Comments 

No.  No.  in  Field _ _ 


45  3 


48  6 

54  6 


60  6 


66  6 


72  6 


78  3 

5  1  1 

2  1 


Positional  uncertainty  or  range  of  observations  in 
the  file  about  the  position  entered  in  bytes  30  - 
44  expressed  in  tenths  of  a  nautical  mile. 

Depth  to  bottom  in  tenths  of  meter  below  sea  level 
at  the  position  entered  in  bytes  30  -  44. 

Depth  of  observations  below  sea  level  in  tenths  of 
a  meter  (height  above  sea  level  is  expressed  as  a 
negative  value)  -  entered  only  if  all  observations 
in  the  file  are  collected  at  the  same  depth 
relative  to  sea  level  -  otherwise  filled  with 
9's. 

Depth  of  observation  below  sea  floor  in  tenths  of 
a  meter  (height  above  sea  floor  is  expressed  as  a 
negative  value)  -  altered  only  if  all  observations 
in  the  file  are  collected  at  the  same  depth 
relative  to  the  sea  floor  -  otherwise  filled  with 
9's.  An  entry  in  this  field  should  be  accompanied 
by  an  entry  in  bytes  48  -  53  wherever  possible. 

Minimum  observation  depth  of  this  file  in  tenths 
of  a  meter  below  sea  level  (height  above  sea 
level  expressed  as  negative  value)  should  be 
filled  with  9's  if  not  known  or  an  entry  has 
been  made  in  bytes  54  -  65. 

Maximum  observation  depth  of  this  file  in  tenths 
of  a  meter  below  sea  level  (height  above  sea  level 
expressed  as  negative  value)  -  should  be  .filled 
with  9's  if  not  known  or  an  entry  has  been  made  in 
bytes  54  -  65. 

Card  sequence  number  "004". 

"5"  record  identifier. 

Flag  to  define  the  usage  of  fields  in  bytes  2  - 
32.  Set  to  "1"  if  fields  are  used  to  define  the 
start  and  end  positions  of  the  file.  Set  to  "2" 
if  fields  are  used  to  define  the  geographic  limits 
within  which  all  observations  in  the  file  were 
collected.  Set  to  "9"  if  the  fields  are  not  used 
-  note  that  fields  not  used  in  bytes  2-32  should 
be  filled  with  9's. 
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A. 3.4  FILE  (CRUISE)  HEADER  RECORD  Continued 
RECORD  ID  5 


Card  Number 

Card  Byte  of  Bytes  Description  of  Field  and  Coranents 

No.  No.  in  Field  _ 


3 

6,1 

10 

7,1 

18 

6,1 

25 

7,1 

33 

5 

38 

1 

39 

12 

51 

6 

57 

10 

67 

11 

78 

3 

6-24 


Start /Southern  Latitude  DDMMHH,  (N/S). 

Start /Western  Longitude  DDDMMHH,  (E/W). 

End/Northern  Latitude  DDMMHH,  (N/S). 

End/Eastern  Longitude  DDDMMHH,  (E/W). 

Note:  DD  or  DDD  =  Degrees,  MM  =  Minutes  and  HH  = 
Hundredths  of  a  minute). 

Code  for  type  of  observation  in  this  file  Table  5. 

Validation  flag  for  data  in  this  file  Table  6. 

Identifier  assigned  to  this  file  by  the  institute 
collecting  (originating)  the  data. 

No.  of  Series  (stations)  within  this  file  -  fill 
with  9's  if  not  known. 

No.  of  data  cycles  within  this  file  -  fill  with 
9's  if  not  known. 

Unassigned  -  leave  blank. 

Card  Sequence  number  "005". 

Blank. 
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Remainder  of  record  is  blank 


A. 3.5  DATA  CYCLE  DEFINITION  RECORD 
RECORD  ID  4 


Card 

No. 

Card 

Byte 

No. 

Number 
of  Bytes 
in  Field 

Description  of  Field  and  Comments 

1 

1 

1 

"4"  Record  ID. 

2 

1 

"6"  next  record  is  a  Series  Header. 

3 

3 

Header  Record  indicate  the  number  of  parameters 
that  are  reported  in  the  data  cycle  record  once 
per  record  (typically  =  000). 

6 

3 

Indicate  the  number  of  parameters  in  each  data 
cycle  (e.g,  for  a  data  cycle  consisting  of  pres¬ 
sure,  temperature,  conductivity  and  salinity  this 
field  =  "004"). 

10 

8 

Blank. 

18 

60 

♦First  part  of  FORTRAN  format  for  reading  the  last 
1900  bytes  of  the  data  cycle  record. 

78 

3 

"001"  card  sequence  number. 

2 

1 

1 

"4"  Record  ID. 

2 

16 

Blank. 

18 

60 

♦Continuation  of  FORTRAN  format  for  reading  the 
last  1900  bytes  of  the  data  cycle  record. 

78 

3 

"002"  card  sequence  number. 

3 

1 

1 

"4"  record  ID. 

2 

16 

Blanks. 

18 

60 

♦Final  part  of  FORTRAN  format  for  reading  the  last 
1900  bytes  of  the  data  cycle  record. 

78 

3 

"003"  card  sequence  number. 

*  For  more  instruction  on  the  use  of  these  fields,  see  Section  4. 
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A. 3. 5  DATA  CYCLE  DEFINITION  RECORD  Continued 
RECORD  ID  4 


Card 

No. 


4 


Card  Number 

Byte  of  Bytes  Description  of  Field  and  Comments 

No.  in  Field 


1  1 

2  1 

3-10  8 

11-13  3 

14-40  27 

41  1 

42-45  4 

46-48  3 

49-56  8 


65  1 

66  1 


"4"  record  identifier. 

Leave  blank  -  reserved  for  future  use. 

Parameter  Code  -  use  standard  parameter  code  as 
far  as  possible,  Table  7. 

Parameter  Discriminator  -  for  use  in  discriminat¬ 
ing  between  parameters  repeated  in  the  same  data 
cycle  or  in  the  same  "header”  area. 

Name  of  the  Parameter  and  its  units  -  plain  language. 

Mode  -  Place  an  "I"  in  this  byte  to  indicate  the 
parameter  is  written  as  an  integer  number  (I  = 
integer). 

Leave  blank. 

*DuRmy  value  code.  (Code  for  default  values). 

Scale  1(*)  Scales  used  to  reduce  the  number  of  bytes 
needed  to  record  the  parameter.  To  recover 
Scale  2(*)  the  parameter  in  the  units  given  in 
bytes  14  -  40,  multiply  the  recorded 
parameter  value  by  Scale  1  and  then 
add  Scale  2.  Set  Scale  1  to  1.0  if  not 
used  and  set  Scale  2  to  0.0.  Use  the 
following  equation  to  recover  the 
parameter.  Real  value  =  value  on  tape  x 
Scale  1  +  Scale  2  where  "real  value" 
means  the  physical  value  in  the  units 
given  in  bytes  14-40. 

Attribute  Flag  -  set  to  'A'  if  the  parameter  is  used 
to  define  the  attribute  of  another  parameter  - 
otherwise  leave  blank. 

Leave  blank  -  reserved  for  future  use. 


*  For  more  instruction  on  the  use  of  these  fields,  see  Section  4 


A. 3.5  DATA  CYCLE  DEFINITION  RECORD  Continued 
RECORD  ID  4 


Card  Number 

Card  Byte  of  Bytes  Description  of  Field  and  Comments 

No. _ No. _ in  Field _ 

67-74  8  Secondary  Partameter  Code  -  if  the  Attribute  Flag 

=  'A'  then  enter  the  Parameter  Code  of  the  param¬ 
eter  whose  attribute  is  being  defined.  If  the 
Attribute  Flag  =  (A*  and  the  parameter  is  a 
function  of  2  other  parameters,  e.g.,  cross 
spectrum  then  enter  the  Parameter  Code  of  the  2nd 
parameter  -  otherwise  leave  blank.  Use  standard 
parameter  codes  as  far  as  possible,  Table  7. 

75-77  3  Secondary  Parameter  Discriminator  -  if  the  Attri¬ 

bute  Flag  -  ’A'  and  the  parameter  whose  attribute 
is  being  defined  itself  has  a  Parameter  Discrimi¬ 
nator  then  enter  that  Parameter  Discriminator  - 
otherwise  leave  blank. 

78-80  3  Card  sequence  number  "004”. 

PARAMETER  2 

5  1-80  80  Card  5  same  as  card  4  but  for  parameter  2,  etc. 

PARAMETER  21 

24  1-80  80  Card  24  (end  of  record). 

PARAMETERS  22-42,  43-63  etc. 

Further  parameters  may  be  included  on  succeeding  Definition  Records  if  necessary 
in  the  same  format. as  above  using  Cards  28-48  for  PARAMETERS  22-42  on  the  2nd 
record.  Cards  52-72  for  PARAMETERS  43-63  on  the  3rd  record  etc.  Hie  1st  three 
cards  of  each  record  used  in  this  way  should  be  formatted  as  follows: 

Cards  25,  49  etc.:  byte  1  should  contain  the  same  entry  as  byte  1  of  card  no. 

"1",  byte  2  should  contain  the  record  identifier  of  the  next  record,  bytes  3-77 

should  be  left  blank  and  bytes  78-80  should  contain  the  card  sequence  no.  ("025”, 

"049",  etc.)  Cards  26,  27,  50,  51  etc.:  as  above  but  byte  2  should  be  left 
blank. 

NOTE:  The  total  number  of  Definition  Records  required  is  deduced  from  the  sum  of 
the  number  of  "header  parameters"  and  the  number  of  "data  cycle  parameters" 

(bytes  3-8  of  card  1).  Parameters  must  be  entered  in  the  sequence  in  which  they 
appear  in  the  "user  formatted  area"  being  defined.  The  "header  parameters"  must 
appear  before  the  "data  cycle  parameters". 
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A. 3. 6 

STATION  HEADER  RECORD 

RECORD  ID  6 

Card 

Number 

Card 

Byte 

of  Bytes 

Description  of  Field  and  Comments 

No. 

No. 

in  Field 

1 

1 

1 

"6"  record  identifier. 

2 

1 

Record  identifier  of  the  next  record.  $  It  is 
a  plain  language  record,  so  set  to  "0". 

3 

9 

Project  name. 

12 

2 

IOC  Country  Code  for  the  country  containing  the 
institution  collecting  the  data  in  this 
series  (i.e.,  the  original  source  of  data), 

Thble  1. 

14 

1 

Enter  "9”  to  indicate  that  following  code  is 

National . 

15 

3 

National  Institution  Code  (if  available)  of  the 
institute  collecting  the  data  in  this  series 
(i.e.,  original  source  of  data). 

18 

18 

Country  -  plain  language  )  original  source  of  data  as 

36 

18 

Institute  -  plain  language)  coded  in  bytes  12  -  17. 

54 

6 

Date  (YYMMDD)  this  version  of  the  series  was 
created  (YY  =  year,  MM  =  Month,  DD  =  Day). 

60 

6 

Time  (HHMMSS)  this  version  of  the  series  was  created 
(HH  =  Hours,  MM  =  Minutes,  SS  *  Seconds). 

66 

12 

Processing  Number  or  Identifier  assigned  to  this 
series  by  data  center. 

78 

3 

Card  Sequence  Number  "001". 

2 

1 

1 

"6"  record  identifier. 

2-3 

2 

Platform  type  code  (primary  platform).  Table  3. 

4-1 

8 

Platform  type  -  plain  language  (e.g.,  Ship,  Buoy, 
Aircraft,  Float,  etc.). 

12 

1 

Meaning  of  record  bytes  13-21,  1-ITU,  2-WMD/I0C, 

9-National  or  local  identifier. 
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A. 3.6  STATION  HEADER  RECORD  Continued 
RECORD  ID  6 


Card 

No. 

Card 

Byte 

No. 

Number 
of  Bytes 
in  Field 

Description  of  Field  and  Comments 

13 

9 

Specific  Platform  Code  -  e.g.,  ship  or  aircraft 
callsign,  mooring  or  buoy  identifier,  etc.,  Table 
4. 

22 

22 

Platform  name  -  plain  language  -  commonly  used 
name  e.g.,  ship  name. 

44 

10 

Reference  No. /Identifier  assigned  by  the  Institu¬ 
tion  originating  the  data  to  the  Station  of  the 
platform,  during  which  the  data  was  collected. 

54 

12 

Date/Time  at  start  of  station  expressed  as 
OCYYMMDDHHMM. 

66 

12 

Date/Time  at  end  of  station  expressed  as 
OCYYMMDDHHMM . 

0C  =  Century,  YY  =  Year,  MM  =  Month,  DD  =  Day, 

HH  =  Hours,  MM  =  Minutes .  Enter  to  appropriate 
precision  leaving  remaining  digits  blank. 

78 

3 

Card  Sequence  Number  "002". 

3 

Secondary  platform  information  in  same  format  as 
record  bytes  81  -  157,  for  example  a  mooring  may 
be  the  primary  platform,  in  which  case  it  is 
relevant  to  specify  the  ship  setting  that  mooring. 

78 

3 

Card  Sequence  Number  "003". 

4 

1 

1 

"6"  record  identifier. 

2 

14 

Date/time  of  start  of  the  series.  Expressed  as 
OCYYMMDDHHMMSS  where  OC  =  Century,  YY  =  Year,  MM  = 
Month ,  DD  =  Day,  HH  =  Hours,  MM  =  Minutes  and  SS  = 
Seconds.  Expressed  in  GMT  and  entered  to  the 
appropriate  precision  leaving  remaining  digits 
blank. 

16 

14 

Date/time  of  end  of  the  series.  Expressed  as  for 

bytes  2-15. 


HI*  MUM-  ■ 
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A. 3.6  STATION  HEADER  RECORD  Continued 
RECORD  ID  6 


Number 

of  Bytes  Description  of  Field  and  Comments 

in  Field 


6.1  Latitude  expressed  as  DDMMHH,  (N/S)  entered  only 
if  all  observations  in  this  series  are  collected 
at  the  same  position  -  otherwise  fill  with  9's. 

7.1  Longitude  expressed  as  DDDMMHH,  (E/W)  entered  only 
if  all  observations  in  this  series  are  collected 
at  the  same  position  -  otherwise  fill  with  9's. 

Note:  DDor  DDD  =  Degrees,  MM  =  Minutes  and  HH  = 
Hundreths  of  a  minute. 

3  Positional  uncertainty  or  range  of  observations  in 

the  series  about  the  position  entered  in  bytes  30 
-  44  expressed  in  tenths  of  a  nautical  mile. 

6  Depth  to  bottom  in  tenths  of  meter  below  sea  level 

at  the  position  entered  in  bytes  30  -  44. 

6  Depth  of  observations  below  sea  level  in  tenths  of 

a  meter  (height  above  sea  level  is  expressed  as  a 
negative  value)  -  entered  only  if  all  observations 
in  the  series  are  collected  at  the  same  depth 
relative  to  sea  level  -  otherwise  filled  with 
9's. 

6  Depth  of  observation  below  sea  floor  in  tenths  of 

a  meter  (height  above  sea  floor  is  expressed  as  a 
negative  value)  -  entered  only  if  all  observations 
in  the  series  are  collected  at  the  same  depth 
relative  to  the  sea  floor  -  otherwise  filled  with 
9's.  An  entry  in  this  field  should  be  accompanied 
by  an  entry  in  bytes  48  -  53  wherever  possible. 

Minimum  observation  depth  of  this  station  in 
tenths  of  a  meter  below  sea  level  (height  above 
sea  level  expressed  as  negative  value)  -  should  be 
filled  with  9's  if  not  known  or  an  entry  has  been 
made  in  bytes  54  -  65. 


6 


A. 3. 6  STATION  HEADER  RECORD  Continued 
Record  ID  6 


Card  Number 
Card  Byte  of  Bytes 

No.  No.  in  Field 


Description  of  Field  and  Comments 


72  6 


78  3 


5  1  1 


Maximum  observation  depth  of  this  station  in 
tenths. of  a  meter  below  seas  level  (height  above 
sea  level  expressed  as  negative  value)  -  should  be 
filled  with  9's  if  not  known  or  an  entry  has  been 
made  in  bytes  54  -  65. 

Card  sequence  number  "004". 

"6"  record  identifier. 


2  1 


3  6,1 

10  7,1 

18  6,1 

25  7,1 


33  5 


Flag  to  define  the  usage  of  fields  in  bytes  3  - 
32.  Set  to  "1"  if  fields  are  used  to  define  the 
start  and  end  positions  of  the  series.  Set  to  "2" 
if  fields  are  used  to  define  the  geographic  limits 
within  which  all  observations  in  the  series  were 
collected.  Set  to  "9"  if  the  fields  are  not  used 
-  note  that  fields  not  used  in  bytes  3-32  should 
be  filled  with  9's. 

Start /Southern  Latitude  DDMMHH ,  (N/S). 

Start /Western  Longitude  DDDMMHH,  (E/W). 

End/Northern  Latitude  DDMMHH,  (N/S). 

End/Eastern  Longitude  DDDMMHH,  (E/W) 

Note:  DD  or  DDD  =  Degrees,  MM  =  Minutes  and  HH  = 
Hundredths  of  a  minute). 

Code  for  type  of  observation  in  this  series  Table 
5. 


38 

1 

Validation  flag  for  data  in  this  series  Table  6. 

39 

12 

Identifier  assigned  to  this  station  by  the  insti¬ 
tute  collecting  (originating)  the  data. 

51 

6 

Fill  with  9's. 
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A. 3.6  STATION  MEADOR  RECORD  Continued 
Record  ID  6 


Card 

Card  Byte 

No.  No. 

57 

67 

78 

S  6  1 

2 

3 

5 

7 

9 

11 

13 

15 

17 

19 

21 

26 

30 


Number 

of  Bytes  Description  of  Field  and  Conments 

in  Field _ _ 

10  No.  of  water  bottles  at  this  station  whose  data  are 
reported  in  this  station  Header  Record. 

11  Unassigned  -  leave  blank. 

3  Card  Sequence  number  "005". 

1  RECORD  ID  =  6. 

1  TRACE  (0  =  N/A,  1  =  Down,  2  =  Up,  3  =  Average  of  up 
and  down).  Default  =  0. 

2  WATER  COLOR,  Forel-ule  Code.  Default  =  -9. 

2  WATER  TRANSPARENCY,  meters  Secchi  disc.  Default  =  -9. 

2  WAVE  DIRECTION,  WMO  Code  0885.  Default  -  -9. 

2  WAVE  HEIGHT,  WMO  Code  1555.  Default  =  -9. 

2  SEA  STATE,  WMO  Code  3700.  Default  *  -9. 

2  WIND  FORCE,  Beaufort  scale.  Default  =  -9. 

2  WAVE  PERIOD,  seconds.  Default  ■  -9. 

2  WIND  DIRECTION,  degrees  east  from  north.  Default  *  -9 

2  WIND  SPEED,  knots.  Default  =  -9. 

5  BAROMETRIC  PRESSURE,  millibars.  Default  =  -9. 

4  DRY  BULB  TEMPERATURE,  degrees  Celsius.  Default  “  -999 

4  WET  BULB  TEMPERATURE,  degrees  Celsius.  Default  =  -999 
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A. 3. 6  STATION  HEADER  RECORD  Continued 

RECORD  ID  6 

Card 

Number 

Card 

Byte 

of  Bytes  Description  of  Field  and  Garments 

No. 

No. 

in  Field 

34  2  WEATHER,  WMO  Code  4501  or  4677.  Default  =  -9. 


36  2  CLOUD  TYPE,  WMO  Code  0500.  Default  =  -9. 

38  2  CLOUD  AMOUNT,  WMO  Code  2700.  Default  -  -9. 

40  3  DROP  RATE  IN  HIGH  GRADIENT  LAYERS,  era  per  sec. 

Default  *  -99. 

43  3  DROP  RATE  IN  LOW  GRADIENT  LAYERS,  cm  per  sec. 

Default  =  -99. 

46  3  SHIP  ROLL  DOMINANT  PERIOD,  seconds  x  10.  Default 

=  -99. 

49  4  SALINITY  OFFSET  FROM  HISTORICAL  POT.  TEMP. , 

S  TEST,  ppm  (NODC  supplied).  Default  =  9999. 

53  33  significant  places  (Default  =  999)  and  power  of 

56  2  ten  (Default  =  99)  for  EFFECTIVE  VERTICAL  RESOLU¬ 

TION  OF  T,  decibars  (NODC  supplied). 

59  33  significant  places  (Default  =  999)  and  power  of 

61  2  ten  (Default  =  99)  for  RMS  TEMPERATURE  NOISE, 

degrees  Celsius  (NODC  supplied). 

63  33  significant  places  (Default  =  999)  and  power  of 

ten  (Default  =  99)  for  EFFECTIVE  VERTICAL  RESOLU¬ 
TION  of  S,  decibars  (NODC  supplied). 

68  33  significant  places  (Default  =  999)  and  power  of 

71  2  ten  (Default  =99)  for  RMS  SALINITY  NOISE,  parts 

per  thousand  (NODC  supplied). 

73  1  Code  =  0  if  test  not  done,  =  1  if  test  performed 

on  this  station,  =  2  if  test  performed  only  on 
other  stations  on  cruise  (NODC  supplied). 

74  2  Blank. 

76  2  Water  bottle  Code:  =  0  if  no  bottles;  *  1  if  on 

separate  Nansen  cast;  ■  2  if  on  Nansen  cast  on 
conducting  cable;  =  3  if  Rosette  downtrace;  *  4 
if  Rossette  uptrace;  =  5  if  Rossette  mixed 
trace. 


A. 3.6  STATION  HEADER  REOORD  Continued 
RECORD  ID  6 


Card  Number 

Card  Byte  of  Bytes  Description  of  Field  and  Comments 

No. _ No. _ in  Field _ 

78  3  "006"  card  sequence  number. 

$7  1  1  "6"  Record  ID. 

2  76  Blank. 

78  3  "007"  Card  sequence  number. 

$8-24  $  The  1360  bytes  on  these  17  card  images  are  not  ordered  by  card  image. 

Rather,  they  are  divided  up  into  35  groups  of  38  bytes  each  (with  30  unused  bytes 
at  the  end  of  the  record).  The  38  bytes  in  each  group  have  the  following  assign¬ 
ments. 

1  4  PRESSURE  at  water  bottle  sample  in  decibars  (or 

DEPTH  in  meters).  Default  =  -9. 

5  5  TEMPERATURE  at  water  bottle  sample  in  millidegrees 

C.  Default  =  -9999. 

10  5  SALINITY  of  water  bottle  sample  in  parts  per 

million.  Default  =  -9999. 

15  4  OXYGEN  of  water  bottle  sample  in  milliliters  per 

liter.  Default  =  -999. 

19  4  SILICATE  of  water  bottle  sample  in  micro  gram  atoms 

per  liter  times  10.  Default  =  -999. 

23  4  INORGANIC  PHOSPHATE  of  water  bottle  sample  in 

microgram  atoms  per  liter  times  100.  Default  =  -999 

27  3  TOTAL  PHOSPHOROUS  of  water  bottle  sample  in 

microgram  atoms  per  liter  times  100.  Default  *  -99. 

30  3  NITRITE  of  water  bottle  sample  in  microgram  atoms 

per  Liter  times  100.  Default  *  -99. 

33  3  NITRATE  of  water  bottle  sample  in  microgram  atoms 

per  liter  times  10.  Default  =  -99. 

36  3  pH  of  water  bottle  sample  times  100.  Default  »  -99. 
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A. 3. 7  $  PLAIN  LANGUAGE  RECORD(S) 

THAT  FOLLOWS  STATION  HEADER  RECORD 


Card 

Card  Byte 
No.  No. 

1  1 

2 

3 

34 

78 

2  1 

2 
14 
26 
34 
78 

3  1 

2 
40 


Number 

of  Bytes  Description  of  Field  and  Conroents 

in  Field _ 

1  "0"  (zero).  Identifies  this  as  a  Plain  Language 

Record. 

1  Next  record  ID.  Identifies  the  type  of  GF3 

record  to  follow. 

31  ''DOCUMENTATION  FOR  STATION  DATA". 

44  Blanks. 

3  "001"  Card  sequence  marks. 

1  "0"  (zero) . 

12  Platform  name. 

12  Cruise  name. 

08  Station  name. 

44  Purpose  of  cruise. 

3  "002". 

1  "0"  (zero). 

38  Institution  name. 

23  Investigator  name.  Name  of  person  responsible  for 

the  data  set. 


64 


3  "TEL". 


67  11  Telephone  number  to  reach  the  investigator  named. 

78  3  "003"'. 


4  1 


1  "0"  (zero). 


2  76  Mailing  address  to  reach  the  investigator  named. 

78  3  "004". 
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Card 

No. 

A.3.7 

Card 

3yte 

No. 

$  PLAIN  LANGUAGE  RECORD(S)  Continued 

THAT  FOLLOWS  STATION  HEADER  RECORD 

Number 

of  Bytes  Description  of  Field  and  Conments 

in  Field 

5 

1 

1 

"0"  (zero). 

2 

16 

"UNDERWATER  UNIT". 

18 

25 

Manufacturer  name. 

43 

12 

Model 

55 

23 

Write  conments  on  deployment  (e.g., 
coupled  to  ship  motion,  free  fall,  yo-yo). 

78 

3 

"005". 

6 

1 

1 

"0"  (zero). 

2 

10 

"DIGITIZER:" 

12 

20 

Digitizer  manufacturer  name. 

32 

8 

Model  n. 

40 

10 

"RECORDER:" 

50 

20 

Recorder  manufacturer  name. 

70 

8 

Model  n. 

78 

3 

"006". 

7 

•  1 

1 

"0"  (zero). 

(19,31*,43?etc) 

2 

25 

Parameter  name  and  units. 

parameter  #  1 

on  CSird  7 

27 

15 

"TARGET  ACCURACY". 

parameter  # 2 

on  Card  19 

42 

10 

The  accuracy  which  the  original  investigator 

parameter  £3 
on  Card  31 

feels  he  achieved  in  the  reported  values  of 
of  this  parameter  in  the  units  given  above. 

parameter  #4 

on  Card  43* 

52 

16 

"TARGET  PRECISION". 

etc. 

*  NOTE:  Card  number  greater  than  24  must  be  continued  on  following  plain 
Language  Records. 
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A. 3. 7  $  PLAIN  LANGUAGE  REOORD(S)  Continued 

THAT  FOLLOWS  STATION  HEADER  RECORD 


Card  Number 

Card  Byte  of  Bytes 

No. _ No. _ in  Field 

68  10 

78  3 

8  11 
(20, 32, 44, etc)  2  22 

24  26 

50  23 

73  5 

78  3 

9  11 

(21, 33, 45, etc)  2  29 

31  10 

41  20 

61  10 

71  7 

78  3 


Description  of  Field  and  Comments 


The  precision  which  the  original 
investigator  feels  he  achieved  in  the 
reported  values  of  this  parameter  in 
the  units  given  above. 

"007"  or  "019"  or  etc. 

"0"  (zero) . 

"SENSOR  SERIAL  NUMBERS:" 

Serial  numbers  of  sensor (s)  used 
at  this  station  for  this  parameter, 
separated  by  comrtas. 

"PERCENT  RAW  DATA  LOSS:" 

Estimate  of  the  data  which  could 
be  measured  but  were  not  included 
in  the  recorded  values,  in  percent. 

"008"  or  "020"  or  etc. 

"0"  (zero). 

"  RAW  DATA.  SAMPLING  INTERVAL:" 

Time  period  over  which  raw  sample 
is  determined,  in  seconds. 

"  SEC.  LOGGING  RATE:" 

Rate  at  which  samples  are  recorded 
in  samples  per  second. 

"SEC**  -  1". 

"009"  or  "021"  or  etc. 
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1 

. 1 

1 

A.3.7  $ 

THAT 

PLAIN  LANGUAGE  REOORD(S)  Continued 

FOLLOWS  STATION  HEADER  RECORD 

B  Card 

Card 

Byte 

No. 

Number 
of  Bytes 
in  Field 

Description  of  Field  and  Comments 

I 

1 

1 

"0"  (zero) 

1  (22,34,46,  etc) 

2 

21 

"LAG  CORRECTION.  STEP" 

23 

3 

Indicate  the  sequence  of  this  step 
during  the  processing  procedure  by 
a  natural  number  increasing  chrono¬ 
logically.  If  no  lag  correction 
is  performed  on  this  parameter  write. 

"  NO". 

26 

6 

"  REF:  " 

:  i 

i 

i 

32 

30 

Author,  date  for  reference  of  algorithm 
used.  Full  reference  must  appear  in 

Plain  Language  Records  following  the 

Tape  Header  Record. 

i 

t 

; 

62 

3 

,  "AV:" 

65 

5 

The  time  over  which  data  were 
smoothed  to  find  time  derivative 
for  lag  correction  (if  appropriate 
to  the  algorithm  used)  in  milli¬ 
seconds 

l 

70 

4 

"TAU:" 

.  74 

4 

The  sensor  time  lag  used  in  the  lag 
correction  (if  appropriate  to  the 
algorithm  used)  in  milliseconds. 

78 

3 

"010"  or  "022"  or  etc. 

ii 

(23,34,47,  etc) 

1 

1 

"0"  (zero) 

2 

17 

"DERIVATION.  STEP  " 

19 

3 

Indicate  the  sequence  of  this  step 
during  the  processing  procedure  by 
a  natural  number  increasing  chrono¬ 
logically.  If  the  parameter  is  not 
derived  from  other  measured  para¬ 
meters  write  "  NO". 

f  i. 
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A. 3. 7  S  PLAIN  LANGUAGE  RECORD(S)  Continued 
THAT  FOLLOWS  STATION  HEADER  RECORD 


Card 

No. 

Card 

Byte 

No. 

Number 
of  Bytes 
in  Field 

Description  of  Field  and  Comments 

22 

5 

"  REF:" 

27 

35 

Author,  date  of  reference  for 
algorithm  used.  Full  reference  must 
appear  in  Plain  Language  Records 
following  the  Tape  Header  Record. 

62 

5 

"FROM:" 

67 

11 

List  abbreviations  of  all  measured 
parameters  from  which  present  para¬ 
meter  is  derived,  separate  by  corona's. 

78 

3 

"Oil"  or  "023"  or  etc. 

12 

1 

1 

"0"  (zero) 

(24,36,48,  etc) 

2 

14 

"EDITING.  STEP  " 

16 

3 

Indicate  the  sequence  of  this  step  during 
the  processing  procedure  by  a  natural 
number  increasing  chronologically.  If  no 
editing  is  performed  on  this  parameter 
write  "NO". 

19 

5 

"REF:" 

12 

(con't) 

24 

32 

Author,  date  for  reference  of  algorithm 
used.  Full  reference  must  appear  in 
the  Plain  Language  Records  following 
the  Tape  Header  Record. 

56 

16 

"PERCENT  DELETED:" 

72 

5 

Give  estimate  of  the  amount  of  data 
deleted  from  this  station  by  editing 
routine,  in  percent. 

77 

1 

Blank. 

78 

3 

"012"  or  "024"  or  etc. 

13 

1 

1 

"0"  (zero). 

(25,37,49  etc) 

2 

16 

"SMOOTHING  STEP". 

>• -'-‘■c*.  i  i .  • 
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PLAIN  LANGUAGE  REOORD(S)  Continued 
THAT  FOLLOW  STATION  HEADER  RECORD 


Card 

No. 


Card  Number 

Byte  of  Bytes  Description  of  Field  and  Comments 

No.  in  Field  _  _ 


18 


21 

26 


57 


3  Indicate  the  sequence  of  this  step 

during  the  processing  procedure 
by  a  natural  number  increasing 
chronologically.  If  no  smoothing 
(other  than  that  associated  with 
the  lag  correction)  is  performed  on 
this  parameter  write  "NO". 

5  "  REF:" 

31  Author,  date  for  reference  of  algorithm 

used.  Full'  reference  must  appear  in  the 
Plain  Language  Records  following  the 
Tape  Header  Record. 

6  "SCALE:" 


63  15 

78  3 

14  1  1 

(26,38,50,  etc)  2  20 

22  3 


25  5 

30  24 

54  18 


Indicate  the  scale  and  units  over 
which  data  were  smoothed  (E.G. 

, 10  Sec). 

"013"  or  "025"  or  etc. 

"0"  (zero) 

"INTERPOLATION.  STEP  " 

Indicate  the  sequence  of  this 
step  during  the  processing  procedure 
by  a  natural  number  increasing 
chronologically.  If  no  interpolating 
is  performed  write  "NO". 

"  REF:" 

Author,  date  for  reference  of  algor¬ 
ithm  used.  Full  reference  must 
appear  in  the  Plain  language  Records 
following  the  Tape  Header  Record. 

'PERCENT  INTERPOLATED:" 
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PLAIN  LANGUAGE  RECORD(S)  Continued 
THAT  FOLLOW  STATION  HEADER  RECORD 


Card 

No. 

Card 

Byte 

No. 

Number 
of  Bytes 
in  Field 

Description  of  Field  and  Comnents 

72 

5 

Indicate  amount  of  reported  data 
that  are  generated  by  interpo¬ 
lation,  in  percent. 

77 

1 

Blank. 

78 

3 

"014"  or  "026"  or  etc. 

15 

1 

1 

"0"  (zero). 

(27,39,51,  etc) 

2 

18 

"CALIBRATION.  STEP  ". 

20 

3 

Indicate  the  sequence  of  this 
step  during  the  processing  proce¬ 
dure  by  a  natural  number  increasing 
chronologically.  If  no  calibration 
is  performed  for  this  parameter 
write  "NO". 

23 

11 

"  DATA  FROM: " 

34 

8 

Day,  month,  year  (separated  by 
slashes)  on  which  laboratory 
calibration  was  performed. 

42 

1 

II  If 
> 

43 

34 

Institution  at  which  the  laboratory 
calibration  was  performed. 

77 

1 

II  II 

I 

78 

3 

"015"  or  "027"  or  etc. 

16 

1 

1 

"0"  (zero). 

(28,40,52  etc) 

2 

3 

Blank. 

5 

9 

"STANDARD: " 

14 

25 

Name  standard  used  at  laboratory, 
e.g.  IPTS  '48,  salt  bath,  etc. 

L 


A-49 


PLAIN  LANGUAGE  REOORD(S)  Continued 
THAT  FOLLOW  STATION  HEADER  RECORD 


Card 

Number 

Gird 

Byte 

of  Bytes 

Description  of  Field  and  Coranents 

No. 

No. 

in  Field 

39 

9 

"ACCURACY: " 

48 

10 

Indicate  the  accuracy  as  determined 
at  calibration,  units  of  parameter 
given  above,  if  unknown  leave 
blank. 

58 

10 

"PRECISION:" 

68 

10 

Indicate  the  precision  as  determined 
at  calibration,  units  of  parameter 
given  above;  if  unknown  leave  blank. 

78 

3 

"016"  or  "028"  or  etc. 

17 

1 

1 

"0"  (zero) 

(29,41,53) 

2 

23 

"OTHER  COMPARISON.  STEP  " 

25 

3 

Indicate  the  sequence  of  this  step 
during  the  processing  procedure 
by  a  natural  number  increasing 
chronologically.  If  no  other 
comparisons  (e.g.  to  classical 
measurements  or  historical  0,S 
curves)  are  made  write  "  NO". 

28 

24 

"  NUMBER  OF  COMPARISONS:" 

52 

56 

65 

78 


1 


9 

13 


Indicate  the  number  of  comparisons 
made  to  determine  a  correction  to 
the  sensor  that  is  applied  to  the 
data  reported  for  this  station. 

"STANDARD:" 

Indicate  the  standard  against  which 
comparisons  are  made,  e.g. ,  reversing 
thermometer ,  historical  potential 
T,S  etc.,  abbreviate  as  needed. 


"017"  or  "029"  or  etc. 
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A. 3. 7  PLAIN  LANGUAGE  RECQRD(S)  Continued 
THAT  FOLLOW  STATION  HEADER  RECORD 


Chrd  Number 

Card  Byte  of  Bytes  Description  of  Field  and  Comments 

_ No. _ No. _ in  Field _ _ 

18  1  1  "0"  (zero). 

(or  30,42,54,  etc)  2  3  Blank. 

5  25  Continue  indicating  standard 

30  14  "AV.  DIFFERENCE:" 

44  10  Indicate  the  mean  difference 

between  the  sensor  value  and 
the  standard  value,  in  units 
of  parameter  given  above. 

54  14  "RMS  DEVIATION:" 

68  10  Indicate  the  rms  deviation  of 

the  differences  between  the 
,  sensor  value  and  the  standard 
value,  in  units  of  parameter 
given  above. 


4T  This  sequence  Is  to  be  repeated  for  every  data  parameter  *  [coogp  _ |PAft _ 

Jncl.uding  water  bottle  parameters.  Begin  with  card  seq.  no.  7 'and  use  a 


A. 3. 8  DATA  CYCLE  RECORD 
RECORD  ID  7 


Card  Number 

Card  Byte  of  Bytes  Description  of  Field  and  Comments 

No. _ No.  in  Field _ 

1  11-  "7"  Record  ID. 

2  1  Record  ID  of  next  record,  typically 

another  Data  Cycle  Record. 

3  4  The  number  of  data  cycles  in  this  record. 

This  number  is  less  than  or  equal  to 
the  maximum  number  of  cycles  per 
record.  The  maximum  #  cycles  =* 
greatest  integer  in  the  ratio  of  1900 
bytes  to  the  number  of  bytes  per 
cycle. 

7  9  The  number  of  data  cycles  in  this 

station  preceeding  the  present 
record.  Should  be  equal  to  the 
.product  of  the  number  of  data  cycle 
records  preceeding  times  the  maximum 
number  of  cycles  per  record. 

16  5  The  record  count.  Indicate  which 

data  cycle  record  of  the  present 
station,  the  present  record  is. 

The  1900  bytes  remaining  in  this  record  are  not  in  card  image  but  contain  an 
integral  number  of  data  cycles.  Each  data  cycle  begins  immediately  after  the 
previous  cycle  ends.  For  the  number  of  parameters  in  the  cycle  and  their 
arrangement  within  the  1900  byte  field  one  must  see  the  Data  Cycle  Definition 
Record  generated  by  the  supplier. 
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A. 3. 9  END  OF  TAPE 
RECORD  ID  8 


Card  Number 

Byte  of  Bytes  Description  of  Field  and  Comments 

No.  in  Field  _ _ 


1  1 

2  1 

3  10 

13  12 


25 

78 

1 

2 

78 


53 

3 

1 

76 

3 


"8”  Record  ID. 

"1"  if  data  are  continued  cm  another  tape, 
"9"  otherwise. 

Set  to  9's. 

Name  or  number  of  following  tape  on 
which  data  are  continued.  If  data 
are  not  continued  set  to  9's. 

Set  to  9's. 

"001"  Card  sequence  number. 

"8"  record  ID. 

Comments  in  plain  language.  $  leave  blank. 
"002",  "003"  etc.  Card  sequence  number. 
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GUIDANCE  NOTES  ON  USE  OF  GF3  $  STD/CTD  IMPLEMENTATION 


A.  4 


A . 4 . 1  Guidance  Note  (1):  Record  Identifier  or  Next  Record 
and  Its  Effect  on  File  Independence 

A. 4. 1.1  Record  Identifier  of  Next  Record 

Certain  computer  systems  require  that  the  format 
of  a  record  should  be  known  before  it  is  actually  read  and, 
in  order  that  this  requirement  may  be  met  without  affecting 
the  versatility  of  the  GF3  format,  the  second  character  in 
each  record  is  reserved  for  the  record  identifier  of  the 
record  that  follows  it.  It  is  essential  that  this  character 
is  entered  correctly.  Please  note  that  EOF  marks  are  not 
considered  as  records  in  this  context,  and  that  the  record 
preceding  an  EOF  should  contain  the  identifier  of  the  record 
immediately  following  the  EOF.  If  the  file  is  continued  on 
another  tape  then  the  End  of  Tape  Record  should  reference 
the  Tape  Header  Record  of  the  following  tape.  If  the  file 
is  not  continued  then  the  End  of  Tape  Record  will  not  be 
followed  by  another  record  and  should  reference  the  dummy 
record  identifier  '9'. 

A. 4. 1.2  File  Independence 

One  method  of  finding  out  which  type  of  record 
ads  a  specific  GF3  Data  File  is  to  examine  the  second 
character  (next  record  identifier)  of  the  last  record  of  the 
previous  file  (whether  it  be  a  Tape  Header  File  or  another 
Data  File).  If  this  method  is  used  then  individual  Data 


Files  cannot  be  considered  independently  of  each  other  and 
this  may  cause  problems  with  certain  operating  systems.  If 
such  is  the  case  then  a  more  appropriate  method  is  obtained 
by  recognizing  that  all  Data  Files  on  a  given  GF3  tape  must 
start  with  the  same  record  type.  On  a  given  tape  this 
record  type  can  be  identified  by  examining  the  second 
character  of  the  last  record  of  the  Tape  Header  File.  Thus, 
on  reading  a  GF3  tape  one  can  in  fact  have  Data  File  inde¬ 
pendence  i.e.  in  reading  a  given  Data  File  one  does  not  need 
to  access  records  in  neighboring  Data  Files.  On  writing  a 
GF3  tape  and  in  particular  the  second  character  of  the  last 
record  in  each  Data  File  one  only  need  know  in  advance 
whether  the  file  is  to  be  followed  by  another  Data  File  or  A 
Tape  Terminator  File  -  in  the  former  case  one  sets  it  as  for 
the  second  character  of  last  record  in  the  Tape  Header  File 
and  in  the  latter  to  '8'  to  identify  the  following  End  of 
Tape  Record. 

It  is  inherent  in  the  use  of  GF3  as  an  exchange 
format  that  Data  Files  are  not  used  independently  of  the 
contents  of  the  Tape  Header  File.  In  an  archive  situation 
this  should  not  introduce  problems  if  the  original  exchange 
tapes  themselves  are  archived.  However,  if  one  wishes  to 
reorganize  the  data  files  (e.g.,  to  reduce  the  number  of 
tapes)  then  of  course  the  lack  of  file  independence  from 
the  Tape  Header  File  may  be  somewhat  inconvenient,  but  it 
should  not  be  too  difficult  at  that  stage  to  merge  the  Tape 
Header  information  into  the  individual  Data  Files.  The  Tape 
Header  Record  itself  can  be  reformatted  into  a  Plain  Lan¬ 
guage  Record  and,  together  with  any  Plain  Language  Records 
and  Definition  Records  in  the  Tape  Header  File,  copied  into 
the  file  heading  of  each  Data  File. 
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A. 4. 2 


Guidance  Note  (2):  USER  FORMATTED  AREA  -  DATA 
CYCLE  PARAMETERS 


The  last  1900  bytes  of  the  data  cycle  record 
constitute  a  "user  formatted  area".  Within  any  "user 
formatted  area"  two  types  of  parameter  are  recognized  i.e. 
"header  parameters"  and  "data  cycle  parameters"  -  the 
"header  parameters"  are  defined  as  those  parameters  that 
occur  only  once  in  the  "user  formatted  area"  of  each 
record  -  the  "data  cycle  parameters"  are  those  that  are 
repeated  as  many  times  as  there  are  data  cycles  in  the 
record  i.e.  each  "data  cycle  parameter"  must  be  repeated  for 
each  data  cycle. 

Please  note  -  in  any  "user  formatted  area"  all  the 
"header  parameters"  if  any,  must  precede  the  "data  cycle 


parameters" 

The  strength  of  GF3  lies  in  the  flexibility  with 
which  the  user  can  define  "header"  and  "data  cycle"  param¬ 
eters  at  the  Data  Cycle  Record  level.  In  a  relatively  simple 
manner,  the  format  provides  a  high  degree  of  versatility  and 
enables  the  user  to  choose  a  "solution"  that  is  tailored  to 
his  requirements.  The  simplest  solution  is  provided  where 
one  has  only  one  type  of  parameter  -  those  constant  for  the 
series  as  a  whole  and  those  varying  with  each  data  cycle  in 
the  series.  In  this  case  one  would  only  need  to  define  "data 
cycle  parameters"  for  the  "user  formatted  area"  of  the  Data 
Cycle  Records.  However,  it  is  recognized  in  GF3  that  this 
simple  solution  is  not  necessarily  the  roost  convenient, 
least  ambiguous  or  indeed  the  most  efficient  way  of  storing 
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all  types  of  STD/CTD  data,  and  that  there  may  be  occasions 
where  it  is  more  appropriate  to  include  "header  parameters" 
within  Data  Cycle  Records  (e.g.,  time  reported  once  per 
record  while  pressure,  temperature  and  conductivity  are 
reported  many  times  per  record). 

A . 4 . 3  Guidance  Note  (3):  User  Formatted  Area  -  FORTRAN 

Format  Description 

A. 4. 3.1  In  reading  Data  Cycle  Records  with  "user  formatted 
area",  the  recipient  of  the  data  needs' to  know  the  FORTRAN 
format  of  the  entire  data  record  (1920  bytes).  There  are  two 
components  of  this  format: 

A:  the  format  for  the  fixed  section  of  the 

record  i.e.,  the  first  20  bytes  in  the  case  of  Data  Cycle 
Records  -  this  component  is  described  as  Part  1  of  the 
FORTRAN  format  statement,  and  can  obviously  be  deduced  from 
the  GF3  record  specification  in  Section  3.  It  is  the 
responsibility  of  the  data  recipient  to  include  this  format 
within  his  reading  program  -  It  is  not  contained  within  the 
Definition  Records. 


B:  the  format  of  the  "user  formatted  area!'  of 
the  record  i.e.,  the  last  1900  bytes  in  the  case  of  Data 
Cycle  Records  -  the  format  of  this  component  is  contained  in 
Parts  2  -  4  of  the  FORTRAN  format  statement,  and  is  included 
in  bytes  18  -  237  of  the  appropriate  Definition  Record. 
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A. 4. 3. 2  FORTRAN  Format  of  the  Fixed  Section  of  the  Data 

Cycle  Record  (i.e.,  Part  1). 

The  FORTRAN  format  description  of  this  section 
takes  the  form: 

(211,  14,  19,  15, 

Note  -  no  closing  bracket 

A.4.3.3  FORTRAN  Format  of  the  "user  formatted  area"  of 

Data  Cycle  Records  (i.e.,  Parts  2-4) 

The  FORTRAN  format  description  of  this  section  is 
given  in  bytes  18  -  237  of  the  appropriate  Definition 
Record.  It  must  be  entered  on  the  Definition  Record  as 
though  it  was  only  needed  for  reading  in  the  "user  for¬ 
matted  area"  i.e.,  it  should  start  wth  an  opening  bracket 
"("  and  should  completely  disregard  the  fixed  area  of  the 
record  being  defined.  It  should  obey  FORTRAN  rules  for 
repetition  -  all  brackets  must  be  paired.  3  i  60  »  180 
bytes  are  allowd  in  the  Definition  Record  for  the  format 
description  (i.e..  Parts  2  -  4)  of  the  "user  formatted 
area".  Probably  60  bytes  will  usually  be  sufficient,  but 
the  extra  space  has  been  allotted  to  allow  for  very  complex 
formats  e.g.,  if  there  is  a  large  number  of  parameters.  -The 
format  is  terminated  by  the  closing  bracket")"  that  pairs 
with  the  opening  bracket  "(".  The  remainder  of  the  180 
bytes  should  be  set  to  blank.  If  it  is  necessary  to  break 
the  format  into  60  byte  parts,  care  should  be  taken  not  to 
leave  significant  blanks  at  the  end  of  each  part.  Prefer¬ 
ably,  terminate  each  part  at  a  comma",". 
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The  repeat  specifications  in  the  format  statement 
must  correspond  with  the  number  of  parameters  recorded  once 
per  record  (Definition  Record  bytes  3  -  5  -  "header  param¬ 
eters")  and  the  number  of  parameters  repeated  each  data 
cycle  (bytes  6  -  8  -  "data  cycle  parameters"). 

A. 4. 3. 4  Examples 

If  in  a  Data  Cycle  Record  three  parameters  are 
recorded  once  per  record  (i.e.,  are  "header  parameters") 
with  another  five  in  each  data  cycle  (i.e.,  "data  cycle 
parameters"),  the  format  of  the  "user  formatted  area"  might 
be 


( 3F8 .2,50 ( 5F9 . 1 ) ) 

or  perhaps 


(2F6.2,F5.3,50(2F6.1,3F11.3)) 

2  +1=3  2  +3=5 

The  second  format  will  be  used  as  the  basis  of 
the  examples  that  follow.  Note  that  in  both  cases  the 
repeat  count  "50"  must  be  large  enough  to  read  at  least  1900 
characters  e.g.,  (2x6+lx5+50x(2x6+3xll ) )  is  greater  than 

1900  for  the  second  case. 

If  there  were  no  header  parameters,  the  five 
parameters  repeated  in  each  data  cycle  could  still  remain  in 
the  Data  Cycle  Record  but  would  now  take  on  the  format 

(50(2F6.1,3F11.3)) 
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In  no  case  should  individual  data  cycles  be 
allowed  to  cross  record  boundaries  i.e.,  each  record  should 
contain  an  integral  no.  of  data  cycles.  In  reading  data 
cycles  from  the  "user  formatted  areas"  of  Data  Cycle  Records 
the  actual  number  of  data  .cycles  contained  in  that  area  is 
entered  as  a  field  in  the  "fixed  area"  of  the  record  (bytes 
3  -  6  in  the  Data  Cycle  Record). 

A. 4. 3. 5  FORTRAN  Format  of  the  Complete  Record 

As  mentioned  in  A. 4. 3.1,  in' reading  Data  Cycle 
Records,  the  recipient  of  data  needs  to  know  the  FORTRAN 
format  of  the  entire  data  record  (1920  bytes)  and  not  just 
the  format  of  its  separate  components.  The  full  format  can 
be  constructed  by  taking  the  format  description  for  the 
fixed  component  from  within  the  program  (see  A. 4. 3. 2)  and 
attaching  to  the  end  of  it  the  format  description  for  the 
"user  formatted  area"  as  read  off  the  Definition  Record 
having  first  removed  its  opening  "(" .  Thus  for  the  exam¬ 
ples  in  A. 4. 3. 4  the  following  full  FORTRAN  format  descrip¬ 
tions  would  be  needed  for  reading  the  records: 

Example  4.3.4 

Case  1  Data  Cycle  Record  Format 
(211,14,19, 15, 3F8. 2 , 50 (5F9. 1 ) ) 

Case  2.  Data  Cycle  Record  Format 

(211 , 14, 19, I5,2F6.2,F5.3,50(2F6.1,3F11.3)) 
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A. 4. 3. 6  Recommended  Format  Types 

$  Only  FORTRAN  format  types  I,  and  X  are  to  be 
used.  These  are  defined  as  follows: 

I_:  the  I  format  is  used  for  arithmetic  values 

which  are  whole  decimal  numbers.  It  is  also  used  for  the 
names  of  parameters  and  variables  when  these  names  have  been 
coded  as  integer  numbers.  Spaces  (blanks)  are  normally  used 
instead  of  leading  zeros  to  fill  out  the  specified  field. 
The  decimal  point  is  never  used. 

Examples: 

Uses 

12345,  bl234 ,  bbbbl  ("b"  means  "blank”) 
12341234,  bbl2222bbl2 

Trailing  blanks  should  not  be  used  to  fill  a 
field  because  these  are  generally  interpreted  as  zeros  by 
computers.  For  example  a  number  written  in  14  format  as 
bl2b  would  be  read  as  0120.  I-forraat  numbers  should  there¬ 
fore  be  written  right  adjusted  (written  at  the  right-hand 
side  of  the  field)  with  blanks  or  zeros  for  fill  on  the 
left.  An  all-blank  field  will  generally  be  read  as  0  (zero) 
or  -0,  depending  on  the  computer  used. 

X:  this  format  is  literally  unspecified.  Fields 

written  with  this  format  will  generally  consist  of  blanks 
but  not  necessarily  so.  Characters  read  under  X  formats  are 
disregarded. 


Format 

15 

214 


Note  that  the  scaling  factors  (Definition  Record 
card  bytes  36  -  51)  for  each  parameter  may  be  used  to 
convert  non-integers  to  integers  according  to  the  following 
formula. 


Value  on  Tape 


Real  Value  -  Scale  2 
Scale  1 


where  "real  value"  means  the  physical  value  in  the  units 
given  in  the  parameter  definition. 


Note  that  the  scaling  factors  themselves  are 
real  and  can  also  be  used  to  convert  data  written  on  the 
tape  in  non  standard  units  to  standard  units. 


Care  must  be  taken  that  the  word  lengths  of 
the  computers  used  are  sufficient  for  the  resolution  needed 
by  each  parameter.  Again,  u$e  of  tte  scaling  factors  may 
help. 

Whenever  parameters  with  an  extremely  wide  range 
of  values  are  to  be  recorded  e.g.,  phyto-plankton  data, 
pollution  data  etc.,  one  is  tempted  to  use  E  formats. 
However,  because  of  the  incompatibility  of  E  and  D  formats 
on  different  computers  the  E  and  D  formats  should  not  be 
used  -  the  problem  may  be  overcome  by  recording  the  mantissa 
and  the  exponent  of  such  parameters  as  separate  parameters 
each  written  in  integer  form.  (See  GF3  parameter  code 
table) . 


A. 4. 3. 7  $  Automatic  Processing  of  STD/CTD  Tapes  in  GF3 

This  can  be  illustrated  by  considering  the  proces¬ 
sing  of  a  Data  Cycle  Record  in  FORTRAN: 

a)  Define  an  integer  array  (IARR)  long  enough  to 
hold  the  maximum  number  of  data  values  there 
can  possibly  be  in  the  user  formatted  area 
i.e. ,  1900  words. 

b)  Read  the  Data  Cycle  Definition  Record  and 
construct  the  complete  format  (see  A. 4. 3. 5)  in 
the  text  array  IFORM. 

c)  Read  the  data  into  the  integer  array  with  the 
statement. 

READ  (a, IFORM)  ID,  NID,  NCYC,  ICYC,  NREC,  IARR 

where  a  =  logical  unit  number  of  tape  drive 

ID  =  record  identification  number  of 

present  record 

NID  =  record  identification  number  of  next 

record 

NCYC  *  number  of  data  cycles  in  present  record 

ICYC  ■  total  number  of  data  cycles  preceeding 
this  record 

NREC  ■  data  Cycle  Record  count  for  the 
present  record. 


A-67 


The  number  of  useful  data  words  in  IARR  will 
be  N  =*  NHPAR  +  (NDPAR*NCYC)  where: 

NHPAR  ■  number  of  header  parameters  in  "user 
formatted  area"  (contained  in  bytes  3  - 
5  of  card  1  of  the  Data  Cycle  Definition 
Record) . 

NDPAR  =  number  of  data  cycle  parameters  in  "user 
formatted  area"  (contained  in  bytes  6  - 
8  of  card  1  of  the  Data  Cycle  Definition 
Record) . 

A. 4. 4  Guidance  Note  (4):  Use  of  the  Parameter  Discrimi¬ 
nator  Field 

It  is  expected  that  most  parameters  will  not 
require  the  use  of  this  entry  in  their  definition  within 
Data  Cycle  Definition  Records.  However,  occasions  do  arise 
when  the  use  of  the  Parameter  Code  (and  the  Secondary 
Parameter  Code  where  appropriate  -  see  4.6)  is  by  itself 
insufficient  to  differentiate  between  parameters  repeated 
within  the  same  data  cycle.  The  Parameter  Discriminator 
field  is  used  solely  for  the  purposes  of  discriminating 
between  such  parameters. 

For  example: 

A  chain  of  5  thermistors  at  5  different  depths 
recording  within  the  same  series  may  produce  data  cycles 
thus: 

time,  temperature,  temperature,  temperature, 
temperature,  temperature 


A-68 


In  this  case  each  of  the  five  temperature  param¬ 
eters  would  have  associated  with  it  a  unique  parameter 
discriminator  -  e.g.,  a  sequential  no.  thus  1,  2,  3,  4  and  5 
respectively.  The  ’depth’  can  then  be  directly  associated 
with  each  parameter  in  turn  in  the  form  of  a  parameter 
attribute  by  specifying  both  the  parameter  code  for  temper¬ 
ature  and  the  parameter  discriminator  (i.e.,  1,  2,  3,  4  or  5 
respectively)  in  card  bytes  67  -  77  of  the  Definition  Record 
defining  each  of  the  parameter  attribute  fields. 

A. 4. 5  Guidance  Note  (5)  -  Dummy  Values 

The  identification  of  dummy  parameter  values  which 
may  occur  in  data  sets  with  different  recording  frequencies 
for  the  parameters  (e.g.,  dissolved  oxygen  content),  or  in 
data  sets  with  missing  values  for  some  parameters  caused, 
for  example,  by  instrument  malfunction,  could  create  a 
problem.  Most  of  the  standard  oceanographic  parameters 
allow  the  ' al 1-9 ’ s-method '  as  a  unique  'dummy  flag'  but  even 
this  is  not  without  problems  in  that 

i)  'all  9 's'  may  in  fact  be  a  reasonable  value  for 
a  parameter  and  ii)  without  examining  the  FORTRAN  format 
description  one  does  not  know  how  many  digits  are  contained 
within  the  stored  value  e.g.  does  one  test  the  value  against 
999  or  9999.  To  overcome  these  problems  the  following 
method  is  used  to  define  "dummy  values"  -  each  parameter 
defined  in  a  "user  formatted  area"  has  associated  with  it  in 
the  appropriate  Data  Cycle  Definition  Record  a  two  digit 
field  "Dummy  Value  Code"  in  the  range  -99  to  99  from  which 
can  be  derived  its  "dummy  value"  as  follows: 


i)  the  tens  digit  defines  the  dummy  digit 


ii)  the  units  digit  defines  the  no.  of  dummy 
digits  in  the  "dummy  value" 

iii)  the  sign  of.  the  "Dummy  Value  Code"  defines  the 
sign  of  the  "dummy  value". 


"Dummy  Value  Codes"  -9,  -8. . .-1,0,2, 3,4. .. .9  are 
meaningless  as  are  Dummy  Value  Codes  with  a  units  digit  of  0 
e.g.,  10,  20,  30  etc.,  -90,  -80  etc.  Examples  of  valid 
codes  are  as  follows: 


"Dummy  Value  Code" 


"dummy  value" 


1  0 


11 

1 

-11 

-1 

12 

11 

-12 

-11 

13 

111 

23 

222 

-23 

-222 

33 

333 

32 

33 

92 

99 

95 

99999 

-95 

-99999 

etc 

etc 

It  is  important  that  the  width  of  the  "dummy 
value"  is  compatible  with  the  width  defined  for  the  param¬ 
eter  field  itself  in  the  FORTRAN  format  description  e.g., 


there  is  no  point  assigning  a  "dummy  value  code"  of  95 
(99999),  -94(-9999)  for  an  14  field  although  "dummy  value 
codes"  of  94(9999),  -93 (-999),  93(999)  etc.  would  be  accep¬ 
table. 


Please  note  The  above  technique  should  be  applied 
only  for  the  value  of  the  parameter  as  stored  on  the  tape 
i.e.,  before  the  factors  -  Scale  1  and  Scale  2  are  applied 
to  it.  Thus  for  a  Parameter  with  Scale  1  =  5.0,  Scale  2  = 
3,  "Dummy  Value  Code"  =  93(999)  the  dummy  value  stored  on 
tape  would  be  999  although  after  conversion  it  would  become 
4998. 
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A.  5 


STANDARD  CODE  TABLES 


A. 5.1  Introduction 

The  following  code  tables  have  been  developed 
for  use  with  the  GF3  format  as  specified  in  Part  I  of 
Appendix  12  to  IOC  Manuals  and  Guides  No.  9. 

Table  1:  IOC  Country  Code 

Table  2:  GF3  Common  Character  Set  for  Magnetic 
Tape 

Table  3:  Platform  Type  Code 

Table  4:  Specific  Platform  Code 

Table  5:  Type  of  Observations  Contained  in  File 
or  Series 

Table  6:  Validation  Flag 

Table  7:  Parameter  Code  (generated  for  STD/CTD 
data) 

Table  8:  Flag  Codes  (generated  for  STD/CTD  data) 

The  maintenance  and  updating  of  these  tables  will  be  pro¬ 
vided  by  the  Intergovernmental  Oceanographic  Commission 
Working  Committee  on  International  Oceanographic  Data 
Exchange  on  a  continuing  basis. 
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TABLE  1:  IOC  COUNTRY  CODE 


Code 

Country 

Code 

Country 

72 

Albania  - 

42 

Indonesia  . 

AL 

Algeria 

IN 

Intergovernmental/International 

08 

Argentina 

45 

Ireland 

09 

Australia 

47 

Israel 

10 

Austria 

48 

Italy 

11 

Belgium 

IC 

Ivory  Coast 

13 

Bolivia 

JA 

Jamaica 

14 

Brazil 

49 

Japan 

15 

Bulgaria 

24 

Korea ,  Republic  of 

12 

Burma 

52 

Lebanon 

18 

Canada 

55 

Madagascar 

19 

Ceylon  (Sri  Lanka) 

MS 

Malaysia 

20 

Chile 

57 

Mexico 

21 

China 

MO 

Monaco 

22 

Colombia 

56 

Morocco 

RC 

Congo 

MZ 

Mozambique 

CR 

Costa  Rica 

64 

Netherlands 

cu 

Cuba 

‘  59 

NeW  Caledonia 

DA 

Dahomey  (Benin) 

61 

New  Zealand 

26 

Denmark 

NI 

Nigeria 

70 

Dominican  Republic 

58 

Norway 

28 

Ecuador 

62 

Pakistan 

27 

Egypt 

PA 

Panama 

75 

El  Salvador 

65 

Peru 

34 

Finland 

66 

Philippines 

35 

France 

67 

Poland 

96 

German  Democratic  Republic 

68 

Portugal 

06 

Germany,  Federal  Republic  of 

73 

Romania 

GH 

Ghana 

SE 

Senegal 

‘36 

Greece 

SL 

Sierra  Leone 

37 

Guatemala 

91 

South  Africa 

GO 

Guinea 

29 

Spain 

38 

Haiti 

SO 

Sudan 

HO 

Honduras 

77 

Sweden 

46 

Iceland 

ZA 

Tanzania,  Onited  Republic  of 

41 

India 

31 

Onited  States  of  America 

86 

Thailand 

99 

Onknown 

88 

Tunisia 

92 

Oruguay 

89 

Turkey 

93 

Venezuela 

90 

Onion  of  Soviet  Socialist 

94 

Vietnam,  Socialist  Republic  of 

Republics 

95 

Yugoslavia 

74 

Onited  Kingdom 

TABLE  2:  ■  GF3  COMMON  CHARACTER  SET  FOR  MAGNETIC  TAPE 


(as  entered  on  Tape  Header  Record,  bytes  162-214) 


I 


* 


Byte 

No. 

Character 
or  Symbol 

BCD 

Octal 

Digits 

EBCDIC 

Hexadecimal 

Digits 

Minsk- 3 2 
Binary 
Bits 

ASCII 

Hexadecimal 

Digits 

162 

-  •  1 

01 

FI 

000  0001 

31 

163 

2 

02 

F2 

000  0010 

32 

164 

3 

03 

F3 

000  0011 

33 

165 

4 

04  . 

F4 

000  0100 

34 

166 

5 

05 

F5 

000  0101 

35 

167 

6 

06 

F6 

000  0110 

36 

168 

7 

07 

F7 

000  0111 

37 

169 

8 

10 

F8 

000  1000 

38 

170 

9 

11 

.  F9 

000  1001 

39 

171 

0 

12 

F0 

000  0000 

30 

172 

— 

13 

7E 

001  0101 

3D 

173 

• 

• 

15 

7A 

001  1111 

3A 

174 

> 

16 

6E 

001  1110 

3E 

175 

blank (space) 

20 

40 

000  1111 

20 

176 

/ 

21 

61 

000  1100 

2F 

177 

S 

22 

E2 

100  1000 

53 

178 

T 

23 

E3 

011  0010 

54 

179 

U 

24 

E4 

100  1001 

55 

180 

V 

25 

E5 

100  1010 

56 

181 

w 

26 

E6 

100  1011 

57 

182 

X 

27 

E7 

011  0101 

58 

183 

Y 

30 

E8 

011  0011 

59 

184 

Z 

31 

E9 

100  1111 

5A 

185 

# 

33 

6B 

000  1101 

2C 

186 

< 

34 

4D 

001  0010 

28 

187 

- 

40 

60 

00 0  1011 

2D 

188 

J 

41 

D1 

100  0011 

4A 

189 

K 

42 

D2 

010  1010 

4B 

190 

L 

43 

D3 

100  0010 

4C 

191 

M 

44 

D4 

010  1100 

4D 

192 

M 

45 

D5 

100  0101 

4E 

193 

O 

46 

D6 

010  1110 

4F 

194 

P 

47 

D7 

011  0000 

50 

195 

Q 

50 

D8 

100  0110 

51 

196 

R 

51 

D9 

100  0111 

52 

197 

* 

54 

5C 

001  1001 

2A 

198 

] 

55 

DO 

001  1000 

5D 

199 

; 

56 

5E 

001  0110 

3B- 

200 

+ 

60 

4E 

000  1010 

2B 

201 

A 

61 

Cl 

010  0000 

41 

202 

B 

62 

C2 

010  0010 

42 

203 

,c 

63 

C3 

011  0001 

43 

204 

D 

64 

C4 

011  1111 

44 

205 

E 

65 

C5 

010  0101 

45 

206 

F 

66 

C6 

100  0000 

46 

207 

G 

67 

C7 

100  0001 

47 

208 

a 

70 

C8 

010  1101 

48 

209 

X 

71 

C9 

101  1000 

49 

210 

• 

73 

4B 

000  1110 

2E 

211 

) 

74 

5D 

001  0011 

29 

212 

r 

75 

CO 

001  0111 

SB 

213 

76 

4C 

001  1101 

3C 

214 

77 

FF 

111  1111 

FF 

See 

Mote 

1 


2 

3 


4 


6 

5 


7 

6 

8 


NOTES: 


1.  The  characters  are  in  collating  sequence  for  BCD. 

2.  Some  BCD  character  sets  use  instead  of 

3.  In  punched-card  code,  a  blank  is  the  2-8  punch  for  BCD,  no 
punches  for  EBCDIC,  and  0-7-8  punches  for  Minsk-32. 

4.  Some  BCD  character  sets  use  "%*  instead  of  "(*. 

5.  Some  BCD  character  seits  use  instead  of  "+". 

6.  EBCDIC  and  some  ASCII  character  sets  use  *{}"  instead  of  "£]*. 

7.  The  Minsk-32  uses  the  vertical  line,  "|",  instead  of  "I". 

8.  This  position  specifies  the  "all  l's"  characters  to  be  used  in 
the  test  file.  These  characters  are  not  to  be  used  on  GF3  data- 
exchange  tapes  except  in  the  test  file. 


Tape  Mark  (end  of  file,  EOF)*: 

7-track  tape  -  a  single  byte  block  (record)  containing  the 
octal  characters  "17".  The  parity  is  even. 

9-track  tape,  NRZI  encoding  (EBCDIC  and  ISO  standard)  —  a 
single  byte  block  (record)  consisting  of  the  Device  Control 
Character,  DC3  ("1”  bits  in  tracks  2,  3,  and  8  only.) 

•Should  EOFs  other  than  these  come  into  use  they  will  be  added 
to  this  table. 


STATIOH/  I  C00e  I  CHARACTERISTIC 


PLATFORM  TYPE  CCgE 


(File  Keader/Series  Header  Record,  Bytea  82-8],  162-163) 


COOL  FORM  0,02 


TABLE  4:  SPECIFIC  PLATFORM  CODE 

For  ships  with  call  signs  consult  the  ITU  list  of  ship's 
call  signs. 


TABLE  5:  TYPE  OF  OBSERVATIONS  CONTAINED  IN  FILE  OR  SERIES 


Code 

?y£e 

11502 

STD/CTD 

11503 

XBT 

11504 

Nansen-type 

TABLE  6:  VALIDATION  FLAG 


(File  Header/Series  Header  Record,  byte  358) 

0  :  no  specification 

1  :  not  suspected 

2  :  suspected 

Flag  refers  to  the  validation  of  the  file  or  series  -  if 
"2"  is  specified  the  plain  language  records  following  the 
file  or  series  header  should  be  consulted  for  details  on  the 
data  that  is  considered  suspect. 


TABLE  7: _ $  PARAMETER  CODES 


Code  Parameter 


1 

pressure 

2 

temperature 

3 

conductivity 

4 

salinity 

5 

sound  speed 

3 

time 

7 

dissolved  oxygen 

8 

water  speed 

9 

water  direction 

10 

speed  north 

11 

speed  east 

12 

depth 

13 

nephelometry 

14 

ambient  light 

15 

electrical  field 

16 

pH 

17 

chloride  ion 
concentration 

18 

oxygen  sensor 

current 

19 

oxygen  sensor 
temperature 

20 

silicate 

21 

inorganic 

phosphate 

22 

total  phosphorous 

23 

nitrites 

24 

nitrates 

25 

ancillary, faster 
response, 
temperature 

26 

platinum 

thermometer 

reading 

and  suggested  units 

decibars 
degrees  Celsius 
millimhos  per  centimeter 
parts  per  thousand 
meters  per  second 
seconds 

milliliters  per  liter 

meters  per  second 

degrees  clockwise  from  North 

meters  per  second 

meters  per  second 

meters 


micro  Ampsres 

degrees  Celsius 
raicrogram  atoms  per  liter 

microgram  atoms  per  liter 
microgrm  atoms  per  liter 
microgram  atoms  per  liter 
microgram  atoms  per  liter 

degrees  Celsius 

degrees  Celsius 
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TABLE  7: _ $  PARAMETER  CODES  Continued 


Code 

Parameter 

and  suggested  units 

101 

trace  =  1  for  down 
average  of  both, 

,  =  2  for  up,  =•  3  for 

0  =  unknown 

102 

water  color, 

Forel-ule  Code 

103 

water 

transparency , 

meters  Secchi  Disc 

104 

wave  direction, 

WMO  Code  0885 

105 

wave  height, 

WMO  Code  1555 

106 

sea  state, 

WMO  Code  3700 

107 

wind  force, 

Beaufort  scale 

108 

wave  period, 

seconds 

109 

wind  direction, 

degrees  clockwise  from  North 

110 

wind  speed, 

knots 

111 

barometric 

pressure 

millibars 

112 

dry  bulb 
temperature 

degrees  Celsius 

113 

wet  bulb 
temperature 

degrees  Celsius 

114 

weather 

WMO  Code  4501  or  4677 

115 

cloud  type 

WMO  Code  0500 

116 

cloud  amount 

WMO  Code  2700 

117 

drop  rate, 

meters  per  second 

118 

ship  roll  period 

seconds 

119 

error  (bias) 

120 

vertical 

resolution 

decibars 

121 

rms  noise 

122 

vertical  resolution 

and  noise  code  >  1  if  present  station 

»  2  if  present  station 

included , 
not  included 

123 

water  bottle  count 

201 

mantissa 

202 

exponent 
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TABLE  8:  $  SUGGESTED  FLAG  CODES  FOR  USE  WITH  DATA  EXCHANGED  VIA  GF3 


Flag  Code 


Flag  Meaning 


100 

200 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

20 

30 

40 


Instability  Density  Max 

Instability  Density  Min 


Depth/Pressure 

Temperature 

Conductivity/Salinity 

Temperature  &  Conductivity/Salinity 

Other 

Other  &  Temperature 

Other  &  Conductivity/Salinity 

Other  &  Temperature  &  Conductivity/Salinity 

All  Parameters 


Interpolated 

Questionable 

Questionable 

Questionable 


(by  originator) 
(by  NODC) 

(by  both) 


APPENDIX  B 

THE  CALCULATION  OF  STORAGE  REQUIREMENTS 
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B.l  INTRODUCTION 

Here  are  discussed  some  of  the  details  of  utiliz¬ 
ing  storage  devices  for  the  data.  A  method  for  the  number 
of  bits  in  storage  that  contain  no  information  (i.e.,  blanks 
or  redundant  digits)  is  presented.  The  basic  approach  is 
to  "pack”  information-containing  bits  in  sequence  without 
regard  to  word  boundaries.  This  avoids  the  wasteful  padding 
with  zeros  that  is  necessary  to  maintain  fixed  word  sizes. 

First  it  is  demonstrated  that  the  cost  of  unpack¬ 
ing  such  data  is  negligible  compared  to  the  cost  of  trans- 
fering  the  data  from  tape  to  computer  memory.  It  is  under¬ 
stood  that  such  packing  saves  both  space  on  the  tape  and  the 
number  of  I/O  operations  required  to  transfer  the  data. 

Next  is  described  the  delta  format,  which  reduces 
to  a  near  minimum  the  number  of  bits  required  to  specify  an 
array  of  parameter  values.  Then  an  example  is  given  of  the 
amount  of  tape  space  saved  if  the  delta  format  were  applied 
to  all  the  STD/CTD  data  estimated  to  reside  within  the 
oceanographic  commmunity. 

The  following  section  describes  the  station  header 
information  requirements.  This  must  be  consistent  with  the 
information  required  in  the  exchange  format.  How  this 
information  might  be  stored  on  the  permanent  tape  is  discus¬ 
sed  here. 


Finally  a  manner  is  presented  in  which  the  data 
and  header  information  might  be  stored  in  temporary,  disk- 
oriented  files  for  independent  access  by  the  computer 

B.2  UNPACKING  COST 

The  unit  of  cost  in  this  analysis  in  the  CPU 

second. 


Some  simple  timing  tests  were  run  to  determine 
the  cost  of  unpacking  data.  The  specific  computer  was  a  CDC 
Cyber  176  (with  a  millisecond  clock),  but  the  purpose  of  the 
exercise  was  to  demonstrate  relative  values,  not  absolute 
ones. 


The  basic  Fortran  construction  was  the  following. 

Do  10  I  -  1,1000  ' 

J  -  J+l 
10  CONTINUE 

In  several  repetitions,  the  total  CPU  time  for  this  was  al¬ 
ways  less  than  one  millisecond.  The  constructions  listed  in 
Table  B.l  were  then  run  (with  the  indicated  elapsed  CPU  time 
for  the  entire  construction,  which  includes  the  above  simple 
FORTRAN  loop). 
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TABLE  B. 1 


No.  Elements 

in  Loop 

Construction 

Loop 

CPU  Time 

1000 

Unformatted  (binary)  reads 
of  512  words  (3840  bytes) 

0.610 

1000 

Extractions  of  a  17  bit 

field-from  a  constantly 

shifting  area  which  did 

not  respect  word  boundaries. 

0.006 

1000 

Extractions  of  a  9  bit  field- 

from  a  constantly  shifting 

area  which  did  not  respect 

word  boundaries. 

0.005 

The  field  extractions  were  performed  by  a  small  assembly 
language  routine,  but  everything  else  was  pure  FORTRAN.  The 
quoted  CPU  times  are  literally  CYBER-176  times  (seconds), 
but  the  only  relevant  point  (of  general  applicability)  is 
the  ratio  of  times.  Typical  in-core  operations  required  to 
implement  the  unpacking  are  at  worst  only  one  percent  of  I/O 
time  -  and  other  measures  would  look  much  better.  It  is 
obvious  that  a  tremendous  payoff  is  available  in  the  data 
compaction  area  (with  the  accompanying  reduction  in  I/O). 

The  above  arguments  are  aimed  at  relevant  consid¬ 
erations  for  any  archive  format.  They  do  not  apply  to 
exchange  formats  (which  must  be  character  oriented  for 


compatibility)  or  in-house  formats  while  the  data  set 
is  being  worked  on,  which  probably  should  be  unpacked, 
unbiased  and  unsealed  for  ease  of  use  in  processing  codes. 


B. 3  THE  DELTA  FORMAT 

This  section  illustrates  practices  to  save  storage 
space  on  tape.  For  the  purposes  of  illustration  assume  an 
original  format  of  4  bytes  (of  8  bits  each)  per  variable  in 
an  IBM  floating  point  format. 


B.3.1  Even  with  the  limited  precision  of  the  original 
format  it  is  far  more  than  is  needed  to  store  oceanographic 
parameters  which  typically  require  accuracies  of  one  part  in 
ten  thousand.  The  extra  space  devoted  to  the  floating  point 
exponent  is  hardly  used  at  all. 

B.3.2  Suppose  we  scale  and  bias  things  such  that  every¬ 
thing  can  be  represented  by  a  positive  integer.  The  bias 
and  scale  factors  must  be  stored  of  course,  but  only  once 
per  station.  Suppose  we  make  the  further  assumption  that 
five  significant  figures  are  totally  adequate  -  certainly 
not  unreasonable  for  physical  measurements  at  sea.  Now, 
each  datum  can  be  represented  in  only  17  bits: 

datum  <  99999  <  131072  -  2*7 


Our  requirements  compared  to  the  original  are  now 


17  bi*s 


4  bytes  x  8  bits/byte 


53  % 


B-5 


',Ve  have  certainly  gained  something,  but  at  what  cost? 
In  order  to  use  our  scaled,  biased  values  packed  away  on 
tape,  we  must  unpack  bit  fields  and  apply  the  inverse  scale 
and  biassing  factors.  It  has  been  shown  that  this  cost  is 
negligible  compared  to  the  I/O  costs. 


B.3.3  Let  us  make  another  somewhat  radical  change  in 
the  storage  mode.  In  B.3.2  each  value  is  allocated  a  full 
seventeen  bits.  If  we  adopt  a  "delta*'  format,  we  can  make 
another  dramatic  savings.  Represent  the  series  as  a  base 
value  (the  first  one,  for  example)  plus  a  series  of  incre¬ 
ments  between  consecutive  values.  For  example,  the  series 
(125,  126,  128,  129,  132,  130,  131,  133)  would  be  repre¬ 
sented  as  a  base  value  of  125  plus  a  delta-series  of  (1,  2, 
1,  3,  -2,  1,  2).  If  we  allow  a  full  17  bits  for  the  base 
value  and  9  bits  for  each  delta  value,  we  see  that  the  space 
required  goes  (for  N  values)  from  17  N  bits  to  17  +  9(N-1) 
bits.  The  former  is  exactly  17  bits  per  datum,  while  the 
latter  coverages  out  to  about  9  bits  per  datum.  These  9 
bits  can  handle  deltas  of  +256  parts  out  of  the  10,000  in 
the  dynamic  range  (i.e.,  +2.5  %).  As  before,  the  additional 
computer  processing  needed  to  recover  the  data  to  usable 
format  is  negligible.  We  now  require  only  approximately 
(9/32)  of  the  original  storage  space.  This  is  a  net  saving 
in  space  of  over  70  percent. 

As  indicated,  a  9  bit  delta  format  is  reasonable 
for  oceanic  changes  of  +2.5%  of  the  dynamic  range.  Some 
stations  may  require  more  than  this,  some  less.  With  addi¬ 
tional  bookkeeping,  like  a  field  that  indicates  the  number 
of  bits  per  delta,  one  can  avoid  making  the  choice  between 
losing  data  and  being  forced  to  define  a  delta  field  so 
large  as  to  provide  too  little  savings. 
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B.  4 


TOTAL  STORAGE  REQUIREMENTS 


This  section  is  concerned  with  the  magnitude  of 
the  problem  -  simply  how  much  data  there  is  to  store. 
Molinelli  and  Kirwan  (1980)  estimate  that  there  are  150,000 
STD  stations  presently  in  hand  and  100,000  CTD  stations. 
The  present  growth  rates  of  relevant  factors  indicates  that 
the  total  inventory  could  triple  in  the  next  five  years. 
Assume  that  a  typical  data  cycle  consists  of  measurements  of 
pressure,  temperature  and  salinity,  and  further  that  there 
are  typically  1,000  data  cycles  per  station  (every  decibar 
to  a  pressure  of  1,000  decibars).  This  yields  a  total  of 
7.5  x  108  data  values  in  the  present  inventory.  Space  for 
header  information,  counters  and  narrative  commentary  must 
be  added  to  this,  but  the  additional  information  is  less 
than  the  basic  data  requirements.  Also,  different  tech¬ 
niques  for  data  storage  will  have  less  effect  on  the  header 
portion  of  the  station  which  contains  a  great  deal  of 
alphabetic  text. 

To  estimate  the  number  of  tapes  required  to  store 
all  these  stations  the  following  calculation  is  performed. 
The  sample  calculation  below  makes  specific  reference  to  IBM 
concepts,  but  has  general  application  as  far  as  the  bottom 
line  (maximum  information  stored  on  a  tape)  is  concerned. 


Maximum  IBM  tape  record  size  *  32750  bytes 


.  32750 


bytes 

record 


x  8 


bits 

byte 


1600 


bytes 

inch 


x  8 


bits 

byte 


20.5  inches  per  record 
of  32750  bytes 


Allowing  0.5  inches  for  an  inter-record  gap: 


2400  x  12 

- --P- - 921—  s  1370  records  per  tape 

2^  inches 
record 


Finally: 


1370 


records 

tape 


x 


32750 


bytes 

record 


45  x  10 


6  bytes 
tape 


(remember,  these  are  8-bit  bytes) 

If  we  assume  (for  the  sake  of  numbers)  that  each  of  the 
7.5  x  108  data  words  in  the  "original"  format  requires  4 
bytes  of  storage,  we  are  led  to  the  following: 

7.5  x  108  datum  x  4  jjgjgg  _  30  x  108 
45  x  106  45  x  106 


»  70  tapes 
with 
headers . 


This  assumes  essentially  one  hundred  percent  efficiency  - 
seldom  realized,  and  is  only  for  the  present  inventory, 
without  tape  backups  (always  a  prudent  policy).  Header 
information  and  less  than  100%  efficient  use  of  tape  space 
could  nearly  double  the  tape  requirements.  The  70%  savings 
offered  by  the  delta  format  represents  a  savings  of  50 
tapes,  of  the  70  for  dat.a  storage.  Assuming  another  50 
tapes  are  required  to  handle  header  information  and  unused 
lengths,  one  is  comparing  70  tapes  using  the  delta  format  to 
120  tapes  without.  This  amounts  to  over  a  40%  reduction  In 
total  tape  demands  by  going  to  a  delta  format,  ford  packing 
of  non-character  header  information  can  further  the  savings. 
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B.  5 


STORAGE  REQUIREMENTS  FOR  STATION  HEADER  INFORMATION 


All  the  information  about  the  station  and  cruise 
provided  by  the  exchange  tape  must  be  stored  on  the  perma¬ 
nent  tape.  The  information  need  not  be  stored  in  the  same 
format,  so  adjustments  for  the  sake  of  saving  space  should 
be  made. 


In  the  exchange  format,  the  station  and  cruise 
information  include  the  time  and  space  coordinates  and 
cruise/station  identifiers  in  the  cruise  header  and  station 
header  records.  Also  included  are  the  surface  and  classical 
observations,  the  data  cycle  definitions  and  the  text 
describing  collection  and  processing  techniques.  In  the 
character  format  used  bn  the  exchange  tapes,  this  informa¬ 
tion  requires  a  total  number  of  bytes  (TB)  that  is  a  func¬ 
tion  of  the  number  of  levels  of  classical  observations 
(NCL),  the  number  of  classical  parameters  at  each  level 
(NCP)  and  the  number  of  STD/CTD  parameters  at  each  level, 
i.e.,  data  cycle  (NSP).  The  form  is 

TB  »  1414  +  NCL  *  38  +  NCP  *  463  +  NSP  *  523. 

For  a  typical  station,  classical  measurements  might  be  made 
at  10  levels  for  each  of  4  parameters  (pressure,  tempera¬ 
ture,  salinity  and  dissolved  oxygen)  while  STD  measurements 
are  made  of  3  parameters  (pressure,  temperature  ajid  salin¬ 
ity).  In  this  case  the  number  of  characters  required  to 
store  the  cruise-station  header  information  is  5,215  bytes. 

More  than  half  of  these  bytes  are  text,  the 
remaining  bytes  are  decimal  digit  numerals  which  can  be 
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represented  by  binary  integers  and  packed  across  word 
boundaries.  Each  decimal  digit  requires  no  more  than  4  bits 
which  is  half  of  an  8  bit  byte  (the  unit  being  used  for  all 
these  discussions  of  storage  requirements).  Therefore,  if 
numerals  are  packed,  only  half  as  many  bytes  are  needed  to 
store  them.  Delta  formatting  is  generally  not  appropriate 
for  header  parameters.  The  split  between  total  text  bytes 

(TTB)  and  total  numerical  bytes  (TNB)  is  given  by  the 

following  relations: 

TB  -  TTB  +  TNB 

TTB  -  866  +  NCP  *  334  +  NSP  *  361 

TNB  =  548  +  NCL  *  38  +  NCP  *  129  +  NSP  *  162. 

After  packing,  the  new  number  of  bytes  required  (TB')  is 
given  by: 

TB'  <  TTB  +  1/2  *  TNB. 

So  for  the  same  typical  station  as  above  the  storage  re¬ 
quirements  are  now  less  than  4,250  bytes. 

More  savings  are  possible  when  one  realizes  that 
a  great  deal  of  this  information  is  constant  for  all  sta¬ 
tions  on  a  cruise.  Since  the  data  are  being  stored  in 
cruise  order  this'  cruise  Information  can  be  stored  at  the 
beginning  of  the  cruise  and  only  those  elements  that  change 
need  be  stored  with  the  station  data.  Retrieval  is  made 
simple  if  text  and  numbers  are  separated.  The  sequence  on 
the  permanent  storage  tape  would  be  as  shown  in  Figure 
B.l. 


SEQUENCE  OF  INFORMATION  IN  CRUISE  FILE 
ON  PERMANENT  STORAGE  TAPE 


etc . 


Figure  B.l 
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The  above  description  identifies  the  approach 
sufficiently  for  this  report.  Further  details  need  not  be 
developed  until  the  stage  at  which  the  approach  is  to  be 
implemented. 

B.6  TEMPORARY  STORAGE  REQUIREMENTS 

Once  the  data  have  been  transferred  to  core 
by  unpacking,  unbiasing  and  unsealing,  further  translations 
should  be  avoided.  After  all  operations  on  and/or  modifi¬ 
cations  to  the  data  set  have  been  made,  then  it  should  be 
transferred  back  to  tape.  (Files  not  affected  by  modifi¬ 
cations  but  that  share  a  tape  with  files  that  are,  should  be 
transferred  to  the  new  tape,  whenever  possible,  using 
computer  utility  routines  rather  than  a  read  tape,  write 
tape  sequence  of  FORTRAN  commands). 

The  data  must  be  on  line,  i.e.,  available  to 
the  computer  by  disk  I/O  commands,  while  programs  are 
executing  that  use  that  data.  The  data  should  be  available 
one  station  at  a  time  so  a  random  access  mode  of  storage  is 
required.  This  implies  using  a  fixed  record  size  which  can 
be  difficult  to  do  when  station  sizes  vary  so  dramatically. 
A  solution  is  achieved  by  selecting  a  reasonable  record  size 
(say  1  disk  track  s  5  x  104  bytes)  and  allowing  a  station 
to  occupy  as  many  random  access  records  as  needed.  The 
first  record  can  contain  the  total  number  of  records 
required  and  each  record  can  contain  the  disk  record  ID  of 
the  next  record.  The  data  retrieval  routine  will  then  use 
this  information  to  reassemble  an  entire  station  in  core. 
At  the  end  of  the  day  the  disc  file  can  be  transferred  to  a 
tape  in  disc  image  using  utility  programs.  The  disk  then 
may  be  reloaded  from  this  tape  the  next  day,  or  whenever 
work  on  the  data  will  recommence. 


A  catalogue  of  which  data  are  in  disk  image 
on  which  tape  or  disc  must  be  kept.  The  catalogue  must  also 
indicate  the  first  disk  record  for  each  station  in  the  data 
set . 

The  5  x  104  bytes  on  each  track  are  sufficient 
room  for  the  header  information  (  5  x  10^  bytes  for  a 
typical  station,  see  B.5)  and  over  3500  data  cycles  (for  the 
three  parameter  cycle  of  the  typical  station,  allowing  4 
bytes  per  floating  point  parameter).  With  3000  to  5000 
tracks  readily  available  (D.  Knoll,  N0DC,  personal  commun¬ 
ication)  the  station  capacity  of  the  system  is  sufficient 
for  most  purposes. 

Unlike  the  permanent  storage  format,  the  cruise 
fixed  information  should  not  be  separated  from  the  station 
information  because  from  the  temporary  storage  the  stations 
must  be  available  independently.  This  is  true  for  the 
production  of  geographically  sorted  copies  of  the  data  for 
dissemination  and  for  the  performance  of  quality  control 
tests. 


